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.

Uint8Array pwn them all!

This week I take a look at the research blog post by @vupen Advanced Exploitation of Mozilla Firefox Use-after-free CVE-2012-0469 . It is one year old vulnerability, but thanks to it, simple idea come into my mind…

Exploitation of this vulnerability presented at vupen’s blogs, was not easy, because it have into arsenal just controlled OR for certain location, and it uses nothing more – which is quite interesting ! Because of that, exploitation grows complexity, and the first step was logical expanding length of string object, for memory leak. As the next move was performed OR at one tag-object targeting its VTable, which ends to arbitrary code execution.

but … in generation of HTML5 and its new features, more easier and more general method could be used for this exploitation

Story of two pointers attack on LFH

This time post will be based on talk by Steven Seeley (Ghost in the allocator) and talk by Chris Valasek & Tarjei Mandt (Windows 8 Heap Internals).

I would like to focus on win8 _HEAP_USERDATA_HEADER structure, and its main perfomance feature – missing validation check per allocation from its block.

Heap Spray – HTML5 really rocks

Some moths ago, on EUSecWest 2012 (by Frederico Muttis & Anibal Sacco), was presented new technique for heap spraying inside HTML5. Main idea is using its new features :

  • WebWorker
  • Canvas
  • UInt8ClampedArray

– to spray the heap quick and efficient, and in addition manipulating data at byte level!


Get every new post delivered to your Inbox

Join other followers: