Appendum to “How Safe is your Link ?” – how to fool LFH

Heap overflow bug can potentionaly lead to alter heap in that way, that you can rule on its allocation / deallocation mechanism. Nowdays it is litle bit harder, because you need to fullfill some subset of prerequisities for choosen technique, and it is in more than less case not possible.

This post will describe how to break even LFH trough plugin, custom PoC for IE10 on win8 CP, vulnerable to winXP-8CP backend attack.

Prerequisites for this blogpost is to read details about introduced exploitation technique :

PoC plugin brief info :

  • block all sites except c:\exploitme.html
  • In case of accessing google.com
    • load & parse c:\blocklist.log
    • parsing file can cause creating another small same sized objects (with vtable) on the heap!
  • (at least one ) heap buffer overflow bug

Introduced BackEnd exploitation & fooling LFH :

    • Initial state of plugin custom heap :

      kinda weird, but it will be exaplained soon …
  • Due to present heap overflow bug, resizable chunk, and nature of file buffer used in plugin code, is possible to do small leak & reusing already used memory – for details of this technique read mentioned materials

    leakstate1leakstate2
  • As i mentioned in plugin are created small vtable objects on the fly

    size of object CBlockFilter is small, and with old know 0x12 consecutive allocations is possible to trigger creation of LFH userdata block. So final plan is :

    • leak memory chunk (MEM_X), which size > particular LFH userdata block (LFH_BLOCK_X) size
    • alloc MEM_X once as user writeable buffer
    • relink MEM_X back to heapsprayed data, where it was originaly placed
    • trigger to alloc LFH_BLOCK_X, but in MEM_X !
    • but fail! This time it seems, something goes wrong (or unexpected right! in view of defender – validity checks are fully implemented ? ) …

ListsInUseUlong, last man standing :

  • when is trigerred LFH some additional pre-allocation is performed and _HEAP_LIST_LOOKUP.ArraySize is updated (depending if ListHints contains bigger chunk than LFH try to alloc).
  • In this state of heap is performed another search -> by using ListsInUseUlong!
  • Search by walking trough ListHints is validation free approach, and in that case we have no problem
  • But search by walking trough ListsInUseUlong, is kinda another approach again no validating, this counts for us, but to the ListsInUseUlong is memory chunk inserted when it is freed and also cleared when it is allocated. Problem is, that we already allocated our memory chunk and due to this it is cleared from ListsInUseUlong, and in attemp to find chunk for LFH userdata block is used ListsInUseUlong… So how to insert it back ?
  • ListsInUseUlong is just bitmap and thats it! Bitmap is able to cover just one deputy per size, and due this have to be clear another option how to link something back even it is already used… 
    In other words, if _HEAP_ENTRY(FLink).Size is same size then bit is not cleared and
    _HEAP_LIST_LOOKUP.ListHints is updated by this FLink
  • Make an update in logic :
    • leak memory chunk (MEM_X), which size > particular LFH userdata block (LFH_BLOCK_X) size  [insert MEM_X to ListInUseUlong]
    • alloc MEM_X once as user writeable buffer [clear MEM_X from ListInUseUlong]
    • relink MEM_X back to heapsprayed data, where it was originaly placed
    • free already used memory chunk (MEM_Y) same size as MEM_X – link MEM_Y to HeapSpray just before MEM_X; MEM_Y.Flink == MEM_X && MEM_X.Blink == MEM_Y [update ListInUseUlong by MEM_Y]
    • alloc memory chunk which use MEM_Y  [update ListInUseUlong by MEM_X]
    • trigger to alloc LFH_BLOCK_X, but in MEM_X !
      listhintstricky1listhintstricky2listhintstricky3listhintstricky4listhintstricky5listhintstricky6
    • everything is fine, LFH userdata is used for CBlockFilter object as well as for user writable buffer ;)
    • now just rewrite some of the VTABLE :P

Implementation :

  • Python craft “c:/blocklist.log” includes 3phases:
    • Leak
    • Link Leak back to ListInUseUlong
    • Alloc Leak also as LFH & rewrite some vtable object

  • html5 heap spray -js handling
    • just relink Leak back

Referenced materials :

This post & idea of technique is based on talk by Brett Moore’s Exploiting Freelist[0] On XP Service Pack 2 and on talk by Matt Conover & Oded Horovitz Windows Heap Exploitation.

And also should be readed some mittigation materials Fermín J. Serna:  Exploits & Mitigations: EMET; Ken Johnson, Matt Miller Exploit Mitigation Improvements in Windows 8.

Conclusions : As was mentioned in presentation How Safe is your Link ? security implementation needs to be implemented whithout shorcuts.
As you can see ListInUseUlong bitmaps usage and logic is imeplemented correctly*. Set and clear bitmap ensures that in _HEAP_LIST_LOOKUP.ListHints are only valid memory chunks and that implies secure alloc / free. But ‘non-secure’ FreeListSearch algo introduced in previous post allow to bypass ListInUseUlong safe mechanism.
So keep in mind that even small security hole can cause troubles and break down another secure processing…

Vulnerable plugin, and .py script for crafting data for this plugin as well, are both just illustrative and not important too much, so i did not it include to sources on github. These was used just for illustrating of idea itself – but if you want to see that, i will provide it to you, just ping me on my email

* AGAIN except missed validation check when checked if FLink is same sized .

Leave a comment

0 Comments.

Leave a Reply


[ Ctrl + Enter ]


Go To Top
Follow

Get every new post delivered to your Inbox

Join other followers: