最近在补之前落下的想学的东西,古河之前已经在微薄里面公布了此漏洞的poc及利用思路,不过在看古河的文章前我先独立分析一下其漏洞成因,记录下自己的分析流程。
操作系统:Win8.1 x86 RTM
浏览器:Internet Explorer 11 32bits (补丁打到KB2909921)
漏洞编号:CVE-2014-0321
微软补丁:MS14-012
直接运行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前还有别的函数调用,如下图所示:
而CInsertSpliceUndo::SetData的父函数则为CSpliceTreeEngine::InsertSplice,通过IDA,发现第一个参数为struct CTreeNode *。因此,释放后被重用的即为struct CTreeNode *,如下图所示:
因此,接下来在CInsertSpliceUndo::SetData处设置断点,查看进入函数时,起参数1是否已经被释放,若没有释放,则进一步跟踪释放位置。
开启gflags.exe的Page Heap功能。
设置条件断点,在进入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("");导致了对象的释放。
基于上面的分析,下次添加断点
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 }"
查看被断下来时的调用回溯,此时调用流程已经比较明显,通过此处的断点状态我们可以获取以下几个信息:
根据以上分析,下次调试设置以下断点,验证执行流程,确定被释放的对象
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
CTreeNode对象被document.write("");释放后,立即进行内存占位,
实际大小为0x60,由于不能通过Create user mode stack trace database功能进行堆回溯,因此在Page Heap开启下无法追踪占位过程。但是通过poc,可以观察到对象已经被稳定占位。
此漏洞的效果总结来说就是对释放后重用的CTreeNode节点对象进行了稳定占位。但由于这个被释放掉的对象的可控性太低,很难在JS里面方便访问,因此利用起来有相当大的难度。
此漏洞的利用难度相当大,最近准备抽时间按照古河提供的思路尝试写EXP进行学习。请先参考资料的链接,了解此漏洞的利用方法。
[1] CVE-2014-0321 - Exploiting IE11 on windows 8.1 32bits:
http://weibo.com/p/1001603732980651659108
原文:http://www.cnblogs.com/Danny-Wei/p/3967463.html