Technical description to presentation : "How Safe is your Link ?"

7/29/2019 Technical description to presentation : "How Safe is your Link ?"

1/14

Peter Hlavaty, @zer0mem

Full technical description of new exploitation technique for windows

win8CP, win7Sp1 also affected

How Safe is your Link ?


2/14

How safe is your link ?

Asnicomentioned in his talkAleatory Persistent Threat, old school heap specific exploiting is dying. And with eachwindows SP or new version, is harder to attack heap itself. Heap management adapt quickly and include newmittigation 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
http://www.zer0mem.sk/?p=147http://www.zer0mem.sk/?p=147https://twitter.com/nicowaismanhttps://twitter.com/nicowaismanhttps://twitter.com/nicowaismanhttp://media.blackhat.com/bh-us-10/presentations/Waisman/BlackHat-USA-2010-Waisman-APT-slides.pdfhttp://media.blackhat.com/bh-us-10/presentations/Waisman/BlackHat-USA-2010-Waisman-APT-slides.pdfhttp://media.blackhat.com/bh-us-10/presentations/Waisman/BlackHat-USA-2010-Waisman-APT-slides.pdfhttp://media.blackhat.com/bh-us-10/presentations/Waisman/BlackHat-USA-2010-Waisman-APT-slides.pdfhttps://twitter.com/nicowaismanhttp://www.zer0mem.sk/?p=147


3/14

byChris ValasektalkUnderstanding the Low Fragmentation Heap

Realworld :

SafeLink is pretty easy check, dont yout think?
https://twitter.com/nudehaberdasherhttps://twitter.com/nudehaberdasherhttps://twitter.com/nudehaberdasherhttp://illmatics.com/Understanding_the_LFH.pdfhttp://illmatics.com/Understanding_the_LFH.pdfhttp://illmatics.com/Understanding_the_LFH.pdfhttp://illmatics.com/Understanding_the_LFH.pdfhttps://twitter.com/nudehaberdasher


4/14

and what do you think about this state ?

Encoding == validation ? Lets see a little bit at algorithms

I) Alloc


5/14

II) Free

and in pseudocode looks like

a) helpers


6/14

b) Free & Alloc

in other words, walking trough freelistdoes not bother about validation !

Decodingo two additional questions can come into mind :

_HEAP_ENTRY.Size = 0; _HEAP_ENTRY.EncodeFlagMask = 0 => should it bedecoded during search ?

_HEAP_ENTRY.Code1= 0xFFFFFFFF ^ _HEAP.EncodeFlagMask => what valueshould be at _HEAP_ENTRY.Size due to xor nature ? (11111111 11111111

11111111 11111111 ^ rnd) big or small ?


7/14

Idea :

small Memory leako 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!

o Implementationa) Helpers


8/14

b) Demonstration of technique


9/14

o Visualisation of techniquea) Initiali state

b) HeapSpray and building own free lists in own buffers


10/14

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 ourheapsprayed buffer -> old school pwn!


11/14

o 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


12/14

c) Fake heap entry chunk on heapspray fake free list, which was usedand linked with valid memory chunk, and no one is noticed of already

pwn-ed state!


13/14

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

o 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 xor-ing, in decoding header, heap_entry Size will be large number

valid _LIST_ENTRY sled in HeapSpray data, one with CompactHeader NULL andsecond 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 malloco Step by step

do small memory leak

force app to alloc & use your leaked chunk (f.e. LFH block for some c++ objectsvtable ? ;)

manualy link it back to spray (RW acces to bufferhtml5heapspray? ) alloc your backlinked leaked chunk again! == own! rewrite some vtable ;)

o Implmentation video demonstration
http://www.zer0mem.sk/?p=5http://www.zer0mem.sk/?p=5http://www.zer0mem.sk/?p=5http://www.zer0mem.sk/?p=5


14/14

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!

Technical description to presentation : "How Safe is your Link ?"

Documents

Transcript of Technical description to presentation : "How Safe is your Link ?"