1. 简介
最近在补之前落下的想学的东西，古河之前已经在微薄里面公布了此漏洞的poc及利用思路，不过在看古河的文章前我先独立分析一下其漏洞成因，记录下自己的分析流程。
2. 实验环境
操作系统：Win8.1 x86 RTM
浏览器：Internet Explorer 11 32bits （补丁打到KB2909921）
漏洞编号：CVE-2014-0321
微软补丁：MS14-012
3. 漏洞分析
3.1. 分析Crash
3.1.1. 运行poc，查看crash
直接运行poc，崩溃后查看状态
看到crash原因是test dword ptr [ecx+24h],30000h ds:0023:41414165=???????? 处引用了无效的内存空间。查看崩溃处的上下文。
在crash时的ecx来自进入函数CTreeNode::ComputeFormatsHelper时的参数1——ecx（请回顾Windows x86调用约定）。那么这个参数1到底又从哪里来呢。进一步回溯父函数：
此时的ecx已经没有发生变化，再次回溯父函数：
通过mov ecx,dword ptr [ebp+8]可以知道crash位置的ecx来自CInsertSpliceUndo::SetData的参数一[ebp+8]。且CInsertSpliceUndo::SetData调用CTreeNode::GetCharFormatHelper前还有别的函数调用，如下图所示：
3.1.2. 释放重用的对象类型
而CInsertSpliceUndo::SetData的父函数则为CSpliceTreeEngine::InsertSplice，通过IDA，发现第一个参数为struct CTreeNode *。因此，释放后被重用的即为struct CTreeNode *，如下图所示：
因此，接下来在CInsertSpliceUndo::SetData处设置断点，查看进入函数时，起参数1是否已经被释放，若没有释放，则进一步跟踪释放位置。
3.2. 跟踪调试、分析漏洞成因
3.2.1. 调试工作准备
开启gflags.exe的Page Heap功能。
3.2.2. 定位对象释放位置
设置条件断点，在进入CInsertSpliceUndo::SetData时断下函数
bu MSHTML!CInsertSpliceUndo::SetData "r $t0 = 0;.foreach (v { k }) { .if ($spat(\"v\", \"*MSHTML!CElement::replaceNode*\")) { r $t0 = 1;.break } }; .if($t0 = 0) { gc }"
第一次断下CInsertSpliceUndo::SetData时，观察参数一：
SetData第一次被断下来，此时对象还未被释放，因此对此对象的释放过程设置断点。
bu ntdll!RtlFreeHeap ".if ( poi(esp+0xc) == 06a9efa0 ){} .else{gc}"
通过跟踪，没有发现问题……发现被释放并占位的是另外一个CTreeNode对象，而且是在第二次调用SetData时，如下图所示
由于Page Heap的作用，导致对象释放后并没有占位成功，对对象进行堆回溯，查看被释放的位置。
由CFastDOM::CDocument::Trampoline_write可见JS中的document.write("");导致了对象的释放。
3.2.3. 观察函数执行流程
基于上面的分析，下次添加断点
bu MSHTML!CFastDOM::CHTMLElement::Trampoline_replaceNode
bu MSHTML!CFastDOM::CDocument::Trampoline_write
bu MSHTML!CInsertSpliceUndo::SetData "r $t0 = 0;.foreach (v { k }) { .if ($spat(\"v\", \"*MSHTML!CElement::replaceNode*\")) { r $t0 = 1;.break } }; .if($t0 = 0) { gc }"
查看被断下来时的调用回溯，此时调用流程已经比较明显，通过此处的断点状态我们可以获取以下几个信息：
- IE内部通过MSHTML!CEventMgr::DispatchEvent进行事件监听并随后通过MSHTML!CEventMgr::Dispatch进行事件分发，分发给相应的事件监听器进行处理。
- IE内部通过jscript9!Js::JavascriptExternalFunction::ExternalFunctionThunk解析并处理HTML中的JS语句
- 在执行replaceNode语句时，IE内部触发了onerror事件，并执行其回调函数，document.write("");操作将导致某个CTreeNode对象被释放
3.2.4. 验证对象释放并重用
根据以上分析，下次调试设置以下断点，验证执行流程，确定被释放的对象
bu MSHTML!CFastDOM::CHTMLElement::Trampoline_replaceNode
bu MSHTML!CFastDOM::CDocument::Trampoline_write //然后跟踪其对某个对象的释放过程
根据堆栈回溯，对MSHTML!CSpliceTreeEngine::InsertSplice+0x11fa处下断点，进一步跟踪分析重用
看看第一、二次进入SetData时的参数一（对象）的情况
具体调试过程如下:
bu MSHTML!CFastDOM::CHTMLElement::Trampoline_replaceNode
bu MSHTML!CFastDOM::CDocument::Trampoline_write //然后跟踪其对某个对象的释放过程
设置快照，方便后边回溯观察对象的释放。下面根据前面Page Heap的对象释放记录，跟踪对象的释放过程
条件断点：
bu ntdll!RtlFreeHeap "r $t0 = 0;.foreach (v { k }) { .if ($spat(\"v\", \"*MSHTML!CMarkup::DestroySplayTree*\")) { r $t0 = 1;.break } }; .if($t0 = 0) { gc }"
上面这个断点设置不太好，需要消耗大量时间，还不如一步步跟踪至
bu MSHTML!CMarkup::DestroySplayTree+0x811
通过跟踪及快照恢复功能发现DestroySplayTree被断下来4次，其中第3次则为后边被释放重用的对象。
对象被释放前的状态：
可见CTreeNode节点对象的创建过程及其大小（0x60）
对象被释放后的状态：
设置如下断点，对onerror回调函数执行完毕后的情况进行跟踪
bu MSHTML!CSpliceTreeEngine::InsertSplice+0x11fa
跟踪至如下位置，即可发现被重用对象作为参数传递进了CInsertSpliceUndo::SetData
3.2.5. 内存占位
CTreeNode对象被document.write("");释放后，立即进行内存占位，
实际大小为0x60，由于不能通过Create user mode stack trace database功能进行堆回溯，因此在Page Heap开启下无法追踪占位过程。但是通过poc，可以观察到对象已经被稳定占位。
3.2.6. 小结
此漏洞的效果总结来说就是对释放后重用的CTreeNode节点对象进行了稳定占位。但由于这个被释放掉的对象的可控性太低，很难在JS里面方便访问，因此利用起来有相当大的难度。
4. 漏洞利用
此漏洞的利用难度相当大，最近准备抽时间按照古河提供的思路尝试写EXP进行学习。请先参考资料的链接，了解此漏洞的利用方法。
5. 参考资料
[1] CVE-2014-0321 - Exploiting IE11 on windows 8.1 32bits: