You are on page 1of 14

Peter Hlavaty, @zer0mem

Full technical description of new exploitation technique for windows win8CP, win7Sp1 also affected How Safe is your Link ?

How safe is your link ?


As nico mentioned in his talk Aleatory Persistent Threat, old school heap specific exploiting is dying. And with each windows SP or new version, is harder to attack heap itself. Heap management adapt quickly and include new mittigation techniques. But sometimes is better to rethink the idea of mittigation and do this technique properly even half version of it will cover all known heap exploit techniques

* in win8 is FreeList little bit restructuralized and renamed to ListHints, i will it rename it back during this description

Mittigations (just 2 selected) :

Safe unlinking

Validation & Encoding headers

by Chris Valasek talk Understanding the Low Fragmentation Heap

Real world :

SafeLink is pretty easy check, dont yout think ?

and what do you think about this state ?

Encoding == validation ?

Lets see a little bit at algorithms

I)

Alloc

II)

Free

a) helpers

and in pseudocode looks like

b)

Free & Alloc

in other words, walking trough freelist does not bother about validation !

Decoding o two additional questions can come into mind :

_HEAP_ENTRY.Size = 0; _HEAP_ENTRY.EncodeFlagMask = 0 => should it be decoded during search ? _HEAP_ENTRY.Code1= 0xFFFFFFFF ^ _HEAP.EncodeFlagMask => what value should be at _HEAP_ENTRY.Size due to xor nature ? (11111111 11111111 11111111 11111111 ^ rnd) big or small ?

Idea : small Memory leak

Step by step HeapSpray valid chain of two connected _LIST_ENTRY structs

HSBlink : _HEAP_ENTRY.{Size, EncodeFlagMask} = 0 HSFlink : _HEAP_ENTRY.Code1= 0xFFFFFFFF

Do Overflow and overwrite _HEAP_ENTRY on freelist, to point Flink to _LIST_ENTRY on HeapSprayed data and _HEAP_ENTRY.{Size, EncodeFlagMask} = 0 ;) Free already allocated memory chunk, with size > overwriten _HEAP_ENTRY.Size ola! do some egg hunt on your heapsprayed buffer . + you can link it back anytime you want! a) Helpers

Implementation

b)

Demonstration of technique

Visualisation of technique a) Initiali state

b)

HeapSpray and building own free lists in own buffers

c)

Memory corruption overflow (sizeof(HEAP_ENTRY) + sizeof(*)) linking original Heap Free list with owned fake free list placed in heapspray

d)

Free used chunk, and memory manager itself will link it to our heapsprayed buffer -> old school pwn!

Memory state (windbg logs) : a) Linked ( == leaked) memory chunk (after technique used)

b)

Fake free list buffer resided on heapspray, used by windows memory manager

c)

Fake heap entry chunk on heapspray fake free list, which was used and linked with valid memory chunk, and no one is noticed of already pwn-ed state!

e)

Lets go pwn memory, and rule above malloc * Live demo *

Key points Setting CompactHeader to NULL ensures that this heap_entry will have Size == 0,

and will be skipped during search algo Setting CompactHeader to (~0) ensures (with very high probability) that after xoring, in decoding header, heap_entry Size will be large number valid _LIST_ENTRY sled in HeapSpray data, one with CompactHeader NULL and second one with (~0) , ensure that Free algo will put valid freed memory chunk inside this chain, and also alloc will unlink it safely whithout any suspection

Own malloc

Step by step

do small memory leak force app to alloc & use your leaked chunk (f.e. LFH block for some c++ objects vtable ? ;) manualy link it back to spray (RW acces to buffer html5heapspray ? )

alloc your backlinked leaked chunk again! == own! rewrite some vtable ;) Implmentation video demonstration

Conclusions : Mittigations are so good as they weekeast point. In this case it is proper implementaion
of functionality. When you try to mittigate something, it is good to do in minimalistic approach and cover just what is already known, but still remain fact, that when you implement something dont forget what piece of code is responsible for what and dont ley performance ahead of functionality / security.

Technique additional info : exploitation technique can be used form WinXP till win8 CP reported to m$ about 2years ago -> recognized as non-critical : I) was not fixed in win8 CP! II) Still present even in win7 SP1 (x64 && x86) fixed in final release of win8 : o added validation also in searching algo!

You might also like