How safe is your link ?

Old school exploitation vs

new mitigations

• Peter Hlavatý• Specialized Software Engineer at ESET• Points of interest :

• vulnerability research• exploit mitigations• kernel development• bootkit research• malware detection and removal algo

• @zer0mem• research blog : http://zer0mem.sk/

#whoami

• As nico mentioned in his talk, Aleatory Persistent Threat, old school heap specific exploiting is dying

• windows version ++ attack difficulty ++

• weak implementation == place for exploiting of mechanism

Introduction

Windows memory management

Lets take a look at algo

Quick lookup at RtlpAllocateHeap FreeLists-UnLink-Search Algorithm

Really, some security improvements in algorithm are obvious...

• Validating / Encoding headers• RtlpAnalyzeHeapFailure• SafeLinking

• code1 = _Heap.EncodeFlagsMask ? code1 ^ _Heap.Encoding.Code1 : code1• valid = code1.Flags ^ (BYTE)code1.Size ^ (code1.Size >> 8) ==

code1.SmallTagIndex• size = code1.Size

• _Heap.EncodeFlagsMask initialy set to default value• _Heap.Encoding.Code1 set to random value

I.Validating / Encoding headers

• cs:RtlpDiSableBreakOnFailureCookie• x64 by default, x86 not!• x86Win binaries by default• What about 3rd party ?

• RtlpGetModifiedProcessCookie• call NtQueryInformationProcess

II. RtlpAnalyzeHeapFailure

• heap_entry.flink.blink != heap_entry.blink.flink || heap_entry.flink.blink != heap_entry

• Pretty easy check don’t you think ?

III. SafeLinking

RtlpHeapAlloc search in FreeLists

• FreeListsSearch• missing validation checks ?

• RtlpAnalyzeHeapFailure• Results in : kill app or not? 3rd party ?

• SafeLink Check• Is implemented smart enough?

Problems ?

Exploitation 1

Show me your gong-fu :: technique

BuildOwnHeap - IDEA

RULLING UNDER ENCODING LOGIC

• LowerBoundary of HEAP_ENTRY.Size : • Interesting test :

_Heap.EncodeFlagsMask & HEAP_ENTRY.Code1• If not matched, then it is not XORED!• What about 0-size ?

Implementation shortcut

RULLING UNDER ENCODING LOGIC

• UpperBoundary (I.) of HEAP_ENTRY.Size : • Interesting xoring value :

_Heap.Encoding.Code1 set to random value

• this case too much random == too much predicatability

• If (HEAP_ENTRY.Size set to 0101010101010101b)then (_Heap.Encoding.Code1 ^ HEAP_ENTRY.Size)

high probability to be big number

Implementation shortcut

RULLING UNDER ENCODING LOGIC

• UpperBoundary (II.) of HEAP_ENTRY.Size : • based on XOR• two heap_entry chunks on freelist

• 1st set HEAP_ENTRY.Size to 0x8000• 2nd set HEAP_ENTRY.Size to 0x0

• After XOR one of HEAP_ENTRY.Size will be for sure equal to 0x8000 which is big number

Implementation shortcut

BuildOwnHeap - implementation

• Looka looka - SafeLink Check ?

Attack!

• SafeLink Check• HeapSpray fake list fulfill conditions

• Validation & RtlpAnalyzeHeapFailure? • I am 3rd Party

• Problems :• Works for x86 binaries• Already fixed in win7sp1

Results ?

Good enough ? … not ...

Can it be improved ?

Seems familiar ?

• Validating / Encoding headers• RtlpAnalyzeHeapFailure• SafeLinking

Quick lookup to RtlpFreeHeap FreeLists-Link-Search Algorithm

• heap_entry.Blink.Flink != heap_entry• …

SafeLinking, changed !?

• Again, no validation here required• Performance vs security ?

RtlpFreeHeap search in FreeLists

Previous IDEA – imporving ..

• What do you think happen with valid chunk, with size is bigger than size of already overwritten HEAP_ENTRY, when it is attempted to be freed ?

1) Memory leak!2) Relinking already used memory!

Final Exploitation

Exploitation 2 - showtime

…improving, improving, success…

• Same as in first attack :• HeapSpray attack• sizeof(HEAP_ENTRY) + sizeof(LIST_ENTRY>Flink)

overflow, that cause overwritting HEAP_ENTRY on FreeList

• Second attack specific :• Ability to force application to free already used ‘good

sized’ memory memory leak• RW access to our heapsprayed buffer relinking

Prerequisites

Attack!

Visualisation of exploitation - init

Visualisation of exploitation - heapspray

Visualisation of exploitation - overwrite

Visualisation of exploitation – free(*)

• Success!

Results

Live Demo

Win7 SP1

• Conclusions :

• Mitigations are as good as they weakest point !• Implement minimalistic approach, but cover all

responsibilities of the code• Speed performance < safe environment

Done

• Reported to microsoft about 2 years ago• But still present in win7sp1, and was usable even in

win8CP !

• In final release of win8 it is finally patched!• FreeListSearch algo now validate each walked

HEAP_ENTRY

Addition technique info

Video Demo

win8 CP, ie10

References

Brett Moore : Exploiting Freelist[0] On XP Service Pack 2http://

www.orkspace.net/secdocs/Windows/Protection/Bypass/Exploiting%20Freelist%5B0%5D%20On%20XP%20Service%20Pack%202.pdf

Chris Valasek : Understanding the Low Fragmentation Heaphttp://illmatics.com/Understanding_the_LFH.pdf

Brett Moore : Heaps About Heaps http://seclists.org/vuln-dev/2008/Jul/0

Alexander Sotirov : Heap Feng Shui in JavaScripthttp://www.blackhat.com/presentations/bh-europe-07/Sotirov/Presentation/bh-eu-07-sotirov-apr19.pdf

Nico Waisman : Aleatory Persistent Threathttp://media.blackhat.com/bh-us-10/presentations/Waisman/BlackHat-USA-2010-Waisman-APT-slides.pdf

… and many others usefull exploit techniques related materials …