Thursday, December 17, 2009

DEP and Heap Sprays

Usually when you need to use a heap spray, you're SOL when it comes to DEP. The reason for this has to do with why you used the heap spray in the first place. In the case of a vtable overwrite you need a chain of pointers to get the job done. A neat way to deal with this is to find an address (like 0x0c0c0c0c) that has a few special properties. It's the same char over and over, it is executable as a NOP generally, and with a spray you can fill memory up to and including that address. If you can't execute on the heap however due to hardware DEP, the fact that it's a NOP doesn't really help you, does it?

Normal vtable Overwrite Crash

mov edx, [eax]     <- Crash occurs here
mov ecx, eax
call dword ptr [edx+4]

In the above example, we control EAX. This means that in order to get
execution, we need EAX to be a pointer, that points to another pointer
(to be placed in EDX) which in turn points to code we wish to execute.
None of these pointers can be volatile for this to work. In this case we
can use a heap spray of 0x0c0c0c0c to satisfy our requirements. If a
heapspray is not possible, we will need to find a real pointer chain. In
order to find such pointers you can make use of the byakugan functionality
!jutsu searchvtptr.

!jutsu searchvtptr 4 call [eax+4]

If, however, the vtable control isn't control of the pointer to the table, but of the table itself (as may be the case in say, a use after free vuln where you have strong heap control and grooming ability) then you only need to find a ptr->ptr and the heap spray isn't needed as a nop sled. You'd only use the heap spray to ensure that despite movement of data, you still hit executable code. The sled will contain a list of return addresses only now. This will require the pointer you choose be a multiple of 4, so that the return addresses are aligned properly. 0x0c0c0c0c is still a good bet for this, but we simply wont fill the heap spray with 0c, we'll instead use a pointer that we'll find in just a moment.

Full vtable Pointer Control Crash

mov edx, [eax]     
mov ecx, eax
call dword ptr [edx+4]    <- Crash occurs here

In this example, we have control over the actual function pointers, rather
than the pointer to the table of function pointers. We no longer need a
ptr -> ptr -> ptr, we only need a pointer to a pointer to executable
code that doesn't move. In this case we can use a heap spray of library
addresses and eschew execution on the protected heap.

So, assuming we have control of data on the heap that a register points to, and also perfect control of EIP, we can use a technique which "flips" the heap to the stack to get execution on DEP systems. What we'd do is find an instruction in memory that wont move around which will move that register into ESP, then return. On non-ASLR systems such as XP, this is a simple matter. By placing this address in EIP, we will effectively make the heap (which we fully control in this case) become the stack. With stack control, we can return to already mapped library code which also will not move, allowing us to make arbitrary system calls, with arbitrary arguments.

Flipping the Heap to the Stack

mov esp, eax

If EAX points to a structure on the heap which you control, then the above
code will make that controlled memory become the effective contents of
the stack. From here you will be able to begin a chained ret2lib style
payload with arbitrary arguments. You can easily find non-moving return
addresses like this code with byakugan's searchOpcode functionality.

!jutsu searchOpcode mov esp, eax

From here, you can go the hard route, mapping pages, re-protecting them, copying your shellcode to them, then returning back to that newly mapped space which is of course mapped executable. The alternative is to just jump to the turn DEP off function (NtSetInformationProcess), and return to your new stack. (See Uninformed v2 article 4: "bypassing windows hardware-enforced dep" for details: http://www.uninformed.org/?v=2&a=4&t=txt

If a vendor tells you that DEP will protect you from a vulnerability, do not assume that your hardware will protect you. Perform other mitigations as well.
Add to Technorati Favorites Digg! This

3 comments:

curtw said...

The heap-to-stack technique reminds me a lot of what Nicolais Waisman taught in his heap class that I took in May 2009 - http://perpetualhorizon.blogspot.com/2009/05/immunitys-heap-overflow-course-review.html

May your chunks always be in alignment, and never blown.

Dino A. Dai Zovi said...

Keep in mind that the NtSetInformationProcess() technique does not work against Permanent DEP when that is available and in use. In that case, you'll have to use a sequence of chained returns (return-oriented payloads/programming), but having a good stack pivot to a region of memory that you control is the first step in this.

DEP is but a door, ASLR is but a window. I'll be back!

-Dino

Snake said...

There is other sequence than can be used and also there most be a pop/ret after mov instruction.for example :
xchng esp,eax
pop reg
ret