View Full Version : IE6 use-after-free PoC

02-26-2013, 03:23 AM
Hi :)

I've just recently started looking into exploit development. I have this PoC that crashes IE6 & according to windbg, is exploitable. But am kinda having a hard time figuring out how to over-write the data of the vftable pointer. Or maybe theres a better approach? Any *pointers*? :)

<SCRIPT type="text/JavaScript">
function initall() {
var tableElem = document.body.firstChild;
if(tableElem.childNodes.length > 0) {

var targetBody = document.createElement('TBODY');

var sampleRow = document.createElement('TR');
var cell = document.createElement('TD');
for(var i = 0; i < 8; i++) {

setTimeout(initall, 1);
<BODY onload="initall();">

Rashid bhatt
02-26-2013, 12:55 PM
Crash occurs at

7d67ec9d 897a20 mov dword ptr [edx+20h],edi ds:0023:018002a0=????????

Stack Trace

0:000> k

ChildEBP RetAddr
0013d0f0 7d67f184 mshtml!CTableLayout::ReleaseRowsAndSections+0xa7
0013d108 7d67f22a mshtml!CTableLayout::ClearTableLayoutCache+0x25
0013d118 7d67f2e3 mshtml!CTableLayout::FlushGrid+0x31
0013d158 7d5a93d9 mshtml!CTableLayout::CreateTableLayoutCache+0x42
0013d160 7d544cc4 mshtml!CTableLayout::EnsureTableLayoutCache+0x29
0013d2a0 7d5069d1 mshtml!CTableLayout::CalcSizeVirtual+0x107

Reading from the source code of mshtml.dll from win2ksrc.rar ltable.cxx (http://read.pudn.com/downloads3/sourcecode/windows/248345/win2k/private/inet/mshtml/src/site/table/ltable.cxx__.htm), we can determine the place where the crash takes place

for (ppSection = _aryBodys, iSection = _aryBodys.Size();
iSection > 0;
iSection--, ppSection++)
(*ppSection)->_iRow = 0; << crash happens here

(*ppSection)->_cRows = 0;

and at this place both edi always is zero and edx can not be controlled

mov dword ptr [edx+20h],edi ds:0023:018002a0=????????

PS: i Dont think its an exploitable crash!

02-26-2013, 01:27 PM

Never knew about the online source-code thingy ;)

and at this place both edi always is zero and edx can not be controlled

mov dword ptr [edx+20h],edi ds:0023:018002a0=????????

PS: i Dont think its an exploitable crash!

Thats what I thought too. So you mean to say, there has to be a way for us to control either of those registers or we can't exploit it? Now whats the whole business with heapsprays?
From what I understand, the above PoC crashes because that location was already freed. Isn't this how the usual use-after-free exploitation is done:

1. Initialize a variable/array on the heap.
2. Nullify an existing (different) tag/pointer.
3. Fill the array initialized at step-1 again,hoping this'll end up overwriting the vftable's pointer we just freed in step-2. (Provided the size of the data was the same? Dunno how this works yet)
4. Try to use the tag/pointer in step-2 & Bingo?

Rashid bhatt
02-26-2013, 01:46 PM
Hey bro!

"Now whats the whole business with heapsprays"

Only memory layout can be controlled with heap sprays not registers!

From what I understand, the above PoC crashes because that location was already freed

The location was never allocated ! we can verify that from the dbg output "0023:018002a0=????????"


02-26-2013, 01:55 PM
Now things are making sense. One more thing, Lets say one finds a "use-after-free" vulnerability. Whats the usual approach to proceed further?

Rashid bhatt
02-26-2013, 02:10 PM
Reliable PHP Exploitation from Windows XP to Windows 7 - Blogs - Garage4hackers Forum (http://www.garage4hackers.com/blogs/3489/reliable-php-exploitation-windows-xp-windows-7-578/) #heap spraying

02-26-2013, 04:35 PM
use after free vulnerabilities notmally exploited in this way for browsers atleast

Create element -> delete that element(here memory is freed bu reference is kept (This is the problem)) -> Heap Spray(so that the memory occupied and freed in last step by element is now filled with your spayed data) -> try to access the same element which was deleted in 2nd step (so as the memory is controlled by you will be accessed as the reference was not deleted)

in very simple way:

create Element -> delete element -> heap spray -> access deleted element

02-26-2013, 10:11 PM
Got the concept :) Thanks.
Now its time to test my theories ;)

02-26-2013, 10:45 PM
one of the best utilities which can be used for use after free vulnerability analysis is
gflags.exe (windbg)

one of the good article.
Debug Heap Issues Using Full Page Heap (http://www.devproconnections.com/article/net-framework2/Debug-Heap-Issues-with-Full-Page-Heap-129771)

05-09-2013, 02:44 PM
I found that using exploitable! from Microsoft gave in many cases indication and a good estimate on how exploitable is a vulnerability.

Try to use it, its pretty straight forward if you already have windbg running - &#33;exploitable Crash Analyzer - MSEC Debugger Extensions - Home (http://msecdbg.codeplex.com/)

If you cannot get it to work, let me know, I can help you with it

05-10-2013, 02:43 PM

The line at which this crash occurred:

mov dword ptr [edx+20h],edi

Seems exploitable to me. If you control edx and edi, or any one of them, it is possible to get a leak and then code execution also both in same vulnerability.
In first step the above line is suitable to overwrite the length of any string and then read the string beyond its limits with increased length and try to fetch some pointers from browser's process memory.
Once we have the pointer we can use it to calculate the ROP gadget and then same vulnerabilityt can be used to overwrite the virtual function of any suitable objects vftable to achieve the code execution.

This way two step chaining of same vulnerability (and this vulnerability) will lead to a reliable remote code execution.

05-10-2013, 09:55 PM
vinnu, that is a good point, though being exploitable and reliable don't always go together

best of luck on the PoC