

IBM's Chris Valesek explains a complex Win32 heap corruption attack - tptacek
http://blogs.iss.net/archive/2009bhtalkexplained.html

======
tptacek
The flaw they're talking about is memory corruption (in this case an integer
overflow).

The problem is that Win32 randomizes the heap to make exploitation of these
flaws difficult.

The solution, which is clever, pivots on the idea of finding a global ("hard")
memory leak and a "soft" memory leak . Soft leaks aren't really leaks, but
rathe allocations with a lifetime under the control of the attacker; for
instance, memory that won't be freed until after a connection is closed.

By making a pattern of allocations that brackets a "soft" leak with two "hard"
links, an attacker can cause the Win32 allocator to free memory of a known
size without that memory being merged into another block (because the adjacent
blocks are leaked).

Because of the way Win32 caches free blocks, doing this means that an attacker
can predetermine the size of a block that will be returned by the allocator,
and can use that information to reliably overwrite heap metadata, and thus
gain control over the process.

------
caf
This is even better kungfu than the Flash bytecode verifier bug (from the same
team!).

