The Hacks Continue: Bypassing the New Speedbumps

Getting through to that glass jaw.

Get It Try It

Windows uses heuristics to determine which functions need stack protection. The heuristics used are heuristics - they're an attempt to assess a total situation. They're not complete. And in fact leave gaping holes big enough for hackers to creep through.

The animated cursor buffer overflow is a good example.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0038

Hackers place a large length value in the header blocks for ANI (animated cursor) files - or for RIFFs, ordinary cursor files, or icon files. The header blocks don't contain string buffers and so no stack cookie is set.

Arrays of integers and pointers are not protected either.

Exception Handling

Microsoft's stack protection can't protect exception handlers on the stack. A buffer overflow can overwrite a handler record for the current function or any other function in the stack unwind. If hackers can raise an exception before the stack cookie check then the overwritten handler record can give them control of the machine.

When DEP is not enabled the exception dispatcher allows SEH handlers anywhere on non-image pages (save for the stack). Hackers can put their shellcode on the heap and use an overwritten exception handler record to jump to it, thus rendering the SafeSEH mechanism completely useless.

Hackers can use an overwritten exception handler record to jump to any code in modules linked in without SafeSEH. This was a technique used to hack into the DNS RPC service vulnerability.

http://www.microsoft.com/technet/security/Bulletin/ms07-029.mspx

Heap Protection

XP SP2 and later lack 'lookaside lists' - single linked lists that keep track of free blocks of 1 KB or less. When a block is allocated from a lookaside list it is removed from the linked list and one of its pointers is written to the head of the list. But at this point there is no checking to make sure this pointer is in fact a valid pointer. The next allocation of the same size will return the same pointer as the pointer to the new block.

[Linked lists of this sort have forward and backward pointers called flink and blink respectively. They're needed to keep track of all allocations. As seen this list can be corrupted.]

Hackers can overwrite the header of a free block on the lookaside list, replacing the flink pointer with an address of their own and writing to that block when the next allocation returns that address.

Matt Conover used this technique in his XP SP2 heap exploitation presentation; Microsoft then replaced the above with the so-called 'low fragmentation heap' which does not suffer from the same vulnerability.

Exploiting Unlink Failures

A more sophisticated technique takes advantage of the fact that detection of memory corruption won't terminate the process but will leave the heap in an unstable state. The most recent version of Windows offers to 'opt in' to terminate processes in this situation.

Overwriting Application Data

Generic exploitation of heap allocators is no longer feasible but hackers can still overwrite application data on a heap such as function, vtable, and object pointers.

Making sure the next block has the right type of data can be accomplished by taking advantage of the determinism of the heap allocator to control the layout of the heap.

Applications Incompatible with DEP

Data execution prevention makes it difficult to transfer control to injected shellcode but there are still alternatives available. Neither IE7 nor FF2 were linked with the 'NX' flag set and thus they didn't have DEP. FF3 does have the flag set as does IE8.

RWX Mappings

But data execution prevention is only effective if it prevents rogue code from writing to executable memory. What happens if memory is marked as both writable and executable? The JVM (Java Virtual Machine) marks pages as both readable, writable, and executable. So hackers can employ Java applets to perform heap spraying attacks similar to standard JavaScript heap spraying attacks and know their target areas will run their code.

Code Reuse

A good exploit technique to bypass DEP is to return control into the code of an image that's already been mapped. Common targets:

• Page mapping or page protection routines. The hackers use system APIs to mark writable pages as also executable. This is typically possible when hackers can control the stack.

• System command or process creation functions. These involve executing a command or launching an application supplied by the hacker. This too is typically possible when hackers can control the stack.

OK so there are ways around things. But how about address randomisation?