technical description to presentation : "how safe is your link ?"
TRANSCRIPT
-
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 ?
-
7/29/2019 Technical description to presentation : "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 -
7/29/2019 Technical description to presentation : "How Safe is your Link ?"
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 -
7/29/2019 Technical description to presentation : "How Safe is your Link ?"
4/14
and what do you think about this state ?
Encoding == validation ? Lets see a little bit at algorithms
I) Alloc
-
7/29/2019 Technical description to presentation : "How Safe is your Link ?"
5/14
II) Free
and in pseudocode looks like
a) helpers
-
7/29/2019 Technical description to presentation : "How Safe is your Link ?"
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/29/2019 Technical description to presentation : "How Safe is your Link ?"
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
-
7/29/2019 Technical description to presentation : "How Safe is your Link ?"
8/14
b) Demonstration of technique
-
7/29/2019 Technical description to presentation : "How Safe is your Link ?"
9/14
o Visualisation of techniquea) Initiali state
b) HeapSpray and building own free lists in own buffers
-
7/29/2019 Technical description to presentation : "How Safe is your Link ?"
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!
-
7/29/2019 Technical description to presentation : "How Safe is your Link ?"
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
-
7/29/2019 Technical description to presentation : "How Safe is your Link ?"
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!
-
7/29/2019 Technical description to presentation : "How Safe is your Link ?"
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 -
7/29/2019 Technical description to presentation : "How Safe is your Link ?"
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!