注：有一处概念模糊，和漏洞利用相关，这里书中的解释也是有问题的。修改了两处内容，三行！！！后面的加粗字体是新添加的内容

原本说这周（写下这段文字的时候已经是上周了...）要看UAF漏洞如何利用的，结果《漏洞战争》中的第一个UAF漏洞是FireFox中的，由于版本太老，Firefox已经不提供symbols了，所以我选择调试第二个漏洞，然后就陷入了IE的大坑。

最终的这篇文章主要集中在了如何对IE进行调试上，按照Poc代码的流程详细分析了IE怎样完成相关操作，并通过删除关键代码，对比调试确定代码作用。最后在漏洞利用上，也对示例代码进行了调试，分析确定了exploit可以发生的原因。文章最后并没有涉及到真正的shellcode，因为那已经是堆喷射和ROP的技术了（而且这个漏洞分析真的花费了太长时间...）。

IE版本：8.0.7600.16385

操作系统：Win 7 64位专业版

Windbg版本：Windbg 6.12 x86

使用IE打开poc文件之后，由于安全设置的缘故，js代码并没有执行，这时用windbg附加到IE进程上，然后右键“允许阻止的内容”，此时进程中断：

可以看到进程执行到了4d3b1874这里：

这个地址没有任何访问权限，看一下函数调用栈的情况：

此时的返回地址是72adc407，看一下这之前的代码：

这是一个很典型的获取对象虚表指针，然后根据偏移调用对应虚函数的结构。ecx中保存了this指针，eax获取虚表指针，调用了偏移0x70处的虚函数。为了获取更多信息，可以开启页堆试一下：

再次开始调试，这次程序断在了刚刚访问ecx寄存器的时候：

根据上面得到的堆信息，进程引用了已经释放的空间，这块空间是通过垃圾回收机制删除的CGenericElement对象。

了解了异常发生的基本原因，我希望先对poc.html中的javascript代码有一个初步的理解，方便明确接下来的分析方向。

下面是我对代码的进一步注释，在这一过程中尝试对某些语句进行删除，重新验证异常是否会出现。

根据以上调试得到的结果，存在以下几个问题：

基于以上提出的问题，进行下一步对javascript代码的调试。首先需要找到对应的DLL文件中的函数是什么。

在CVE-2011-0027的整数溢出漏洞的分析过程中，书中提到了一个确定和recordset相关的IE函数的方法，需要到https://www.geoffchappell.com上去搜索。使用这个方法可以找到CDocument类中的createElement函数。

除此之外，在此次漏洞分析中，书中也写到了可以直接在windbg中对函数进行搜索。具体使用哪种方法还需要结合上下文，以及搜索结果进行选择。

按照书中所说，搜索mshtml!*document*createElement*

先看第一个函数，在IDA中打开mshtml.dll并找到对应函数。

之后是一系列CreateElement函数的调用：

直接在CMarkup::CreateElement处下断点，根据IDA中CreateElement调用位置，在windbg中下断点：

步入之后很快能到达下面的代码位置：

其中mshtml!g_atagdesc是一系列函数的索引表：

edi寄存器中保存了该索引表的偏移，最终得到函数CSpanElement::CreateElement的地址，并进行了调用：

在IDA中看一下这个函数干了什么：

可以看到这个函数通过HeapAlloc分配了大小为0x28个字节的空间，然后调用了CElement::CElement创建元素，并将相关数据写入到分配的空间中。

！！！
！！！
！！！

注意这里分配的空间大小，每个元素都不一样，0x28是span元素分配的大小，CGenericElement分配的大小是0x38。后面的漏洞利用脚本，控制循环的数值13就是从这里来的

CElement::CElement 的内容：

eax寄存器指向的是之前HeapAlloc分配的空间，可以看到这个函数在向这个空间填入数据，最后将其作为返回值返回。

总结一下，createElement的流程如下：

因此我们可以通过在mshtml!CreateElement和mshtml!CElement::CElement设置断点，获得createElement过程中创建的元素类型以及分配空间的地址及内容：

在设置第一个断点的时候，出现了两个函数：

我查看了一下汇编代码，在第二个位于71084bb0的函数那里找到了相似代码：

所以选择这个函数设置断点：

到此为止，通过分析createElement底层执行的代码，我们已经知道怎样获得函数执行期间创建的堆空间的地址及其内容了。

接下来按照同样的方法，确定appendChild这个函数在底层干了什么

在windbg中搜索和appendChild相关的函数：

代码中有两类进行appendChild的操作，分别是向body和span元素中添加子元素：

从函数名来看，mshtml!CElement::appendChild和mshtml!CDocument::appendChild比较可疑。在IDA中搜索后者，可以发现CDocument::appendChild直接调用了CElement::appendChild。

直接在IDA中跟踪一下函数的调用流程，根据函数名称可以大致判断其功能，得到下面的结果：

从上面的流程中可以知道，程序是在InsertBeforeHelper中获得了元素在DOM树中的插入位置，然后开始进行插入，最终到达InsertElementInternal函数，才真正在堆中分配一个空间，所有数据的赋值一定是在之后才发生的。

根据以上结论，在CMarkup::InsertElementInternal函数设置一个断点，进行详细的调试，判断空间分配后发生的什么。

程序断在CMarkup::InsertElementInternal之后，继续步进，到达HeapAlloc函数：

HeapAlloc分配的空间首地址为eax中的值0d008fb0。

当执行完HeapAlloc之后，程序调用CTreeNode::CTreeNode函数创建对应想要添加元素的TreeNode，

之前HeapAlloc创建的空间作为this指针传递给了CTreeNode::CTreeNode函数，并且会作为返回值返回（从IDA中得知）。因此在该函数执行完之后，看一下之前分配的空间：

可以看到这次添加的元素是span。

也就是说，在进行appendChild操作时，程序会分配一个大小0x4C的空间，该空间用于存储要添加元素的CTreeNode结构，该结构中存储了和要添加的元素有关的信息。

还是按照之前分析createElement的方法，在执行完CTreeNode::CTreeNode函数之后的位置设置断点，这次要输出CTreeNode的内容：bu mshtml!CMarkup::InsertElementInternal+0x23d "ddp eax L13;g"

到目前为止我们已经跟踪了createElement和appendChild的执行流程，知道在哪里设置断点可以获得分配的堆块空间的地址，以及如何显示空间中的内容。

接下来就要看poc中剩余的代码对已经分配的这些空间有什么影响了。

在调试之前，先看一下offsetParent是什么东西：

那么offsetParent就是距离该子元素最近的进行过定位的父元素（position：absolute relative fixed），如果其父元素中不存在定位则offsetParent为：body元素

因此如果没有设置过这个值，f0的offsetParent应该是body元素，但是在代码中把这个值设置成了null。

还是像之前一样，确定一下和offsetParent有关的函数是什么：

从函数名来看，有关的函数可能是：

在IDA中查找，可以看到后者调用了前者。这样的话，可以直接在CElement::GetOffsetParentHelper设置一个断点，然后查看函数执行前后，目标空间数据的变化情况。

根据以上结论，我们可以设置以下断点：

设置好断点执行，会得到和每个元素相关的堆块空间的地址，然后程序断在CElement::GetOffsetParentHelper的开头。此时我们可以按照dd element_addr la;以及ddp treenode_addr l13;的格式输出所在地址处的数据。

之后按Shift+F11跳出当前函数，再次进行一次上面的堆块空间内容的输出，就可以得到函数执行前后，目标空间数据的变化情况了。

整理如下：

首先看一下上图中，程序创建的元素名称，可以看到倒数第二个是CGenericElement元素，还记得我们一开始定位漏洞的位置，根据调试器的输出，已经知道异常产生的原因是一个CGenericElement被释放重引用了，所以之后应该重点关注这个元素对应的堆块空间的变化情况，以及其他元素对于这个元素的引用情况。

除此之外，观察上图中同一列数据，根据数值间的关系以及IE5.0源码，可以得出以下结论（仅作参考，帮助分析）：

CTreeNode+0x44(4字节)：CTextBlock结构指针。

源码和数值关系都没看出来，最终在windbg中得到了这个值的涵义：0cec1ff4 0d186fa0 71fc6cc8 mshtml!CTextBlock::vftable'`

检查了几个不同元素，得到的都是同一结构的指针；

CElement+0x14(4字节)：同一元素CTreeNode地址；

之后执行的代码是：

按照相同的方法找到和innerHTML有关的函数，并设置断点：

到目前为止断点设置情况：

最后得到如下图的数据变化情况：

从上图可以发现：

我觉得第2点中存在的现象肯定是有一些问题的，CElement和TreeNode之间的联系被单方面中断了，这就导致最后垃圾回收之后，TreeNode那里的数据完全没变化。而且第1点中变化的那几个字节的具体作用目前也不清楚，不知道是不是和这个漏洞有关系。

关于第一点，我在下一小节进行了调试，先来看第二点。仔细查看一下CTreeNode+0x44这个位置的值是什么意思：

注：因为多次调试，这里的值发生了变化。

所以这个位置保存了一个指向CTextBlock的指针，而执行完f0.offsetParent=null;之后，CGenericElement的CTreeNode里面就多出来了一个CTextBlock，我们设置一个断点看一下是怎么来的：

看一下函数调用流程：

也就是说IE在设置完offsetParent之后进行了一次渲染。在IDA中看一下CTreeNode::SetLayoutBlock的代码：

所以程序在这里给CTreeNode设置好了CTextBlock的值，在windbg中看一下这里面的内容：

几个看起来有意义的数据都进行了注释，其中倒数第二个数据看起来也是一个地址，看一下里面是什么内容：

也就是说，IE在执行完offsetParent之后进行了一次渲染，为相关元素构造了CTextBlock结构，添加了它的指针。

接下来继续分析，设置完所有这些断点，然后一直执行到垃圾回收之前，看一下和CGenericElement有关的空间情况：

也就是说，直到执行CollectGarbage函数之前，这两块堆空间还是正常的占用状态。接下来F5继续执行，程序直接到达异常：

目前我们已经对分配的堆块空间有了一定了解，可以发现0ce20fc8就是CGenericElement的CElement的地址。

可以向上翻一下3.2小节的内容，那时我们就已经得出了异常出现是因为垃圾回收已经释放了一个叫做CGenericElement的元素的空间，而后面又对这个空间进行了引用。但是当时虽然发现了这一点，由于对内部机制完全不了解，所以毫无头绪。

现在我们看一下函数调用情况：

有一个地址看起来特别眼熟：0cec1fb0，这是CGenericElement的TreeNode的地址从函数调用情况中，可以找到最早引用0cec1fb0这个地址的是mshtml!ISpanQualifier::GetFancyFormat+0x5a函数，在3.4.3小节最后推出的结论部分，我们曾经提到过Fancy Format这个东西，它位于CTreeNode+0xC这个DWORD的16-31位。

接下来在IDA中跟踪一下ISpanQualifier::GetFancyFormat这个函数的调用流程，不想截太多的图，这里只贴出关键的代码：

检查上面ISpanQualifier::GetFancyFormat的调用流程：

根据下半部分GetFancyFormat调用函数的情况会发现，只有Fancy Format的值小于0，函数才会继续深入，进一步调用ComputeFormats函数，而如果Fancy Format的值不符合要求，函数是不会对这个元素进行处理的。而在设置完offsetParent之后，Fancy Format的值就变了，不再小于0。

因此在开始设置innerHTML之前，即程序刚刚进入CElement::put_innerHTML函数之后，在Fancy Format所在的位置，即0cec1fbc这里设置一个读断点，程序执行后断在这里：

此时的函数调用情况：

我们在IDA中看一下这个函数的代码：

可以看到执行完这个函数，Char Format和Fancy Format又设置成了-1。但是此时CElement中仍旧保存着CTreeNode的值：

在这个位置上也设置一个读断点，然后继续执行：

也就是说在设置innerHTML为空的时候，通过CElement::DelMarkupPtr，删除了CElement中对于CTreeNode的引用。

上半部分显示了CTreeNode是怎样传入这个函数的，最终追踪到了SRunPointer::SpanQualifier函数，再往前由于缺少函数调用流程，不知道该检查哪个函数。

所以现在需要确定SRunPointer::SpanQualifier函数中的a1是什么东西。

要在SRunPointer::SpanQualifier这个函数上设置一个断点，为了确保代码能够执行到这个函数中最后的return v1[3];返回语句，需要设置条件断点

使用这个条件断点执行到异常发生会输出一长串信息，因为断点命中了很多次，只取最后一次的输出：

仔细检查一下相关的地址：

根据上面的输出结果，我们知道SRunPointer::SpanQualifier函数中的a1指向的是一个CTextBlock，[a1+4]指向的是一个列表，上面的第二个输出，可以看出每16个字节是列表中的一项，每项中又包含四个不同的数据，其中第三个数据是CTreePos的地址，第四个数据是CTreeNode的地址。函数返回的就是这个CTreeNode的地址。

所以这个结构有没有很熟悉，和我们在3.4.4中分析CTextBlock的时候，遇到的倒数第二个数据指向的位置结构相同。这里为了方便，沿用《漏洞战争》使用的名称，把这块数据叫做element_array。

上面的调试分析更多的是让自己对和此次漏洞有关的数据结构有所了解，同时也初步确定了poc代码中一些元素的作用，但是可能还有一些作用不太清晰。接下来会通过修改Poc代码，删除对应元素的方式，确定各元素对于最终异常的产生有什么印象。

经过调试发现，一直到执行完垃圾回收，CTreeBlock处仍旧包含已经释放的CGenericElement元素的CTreeNode。因此问题应该出在脚本执行结束后的渲染部分，它可能没有遍历CTreeBlock。

为了验证这一点，在element_array所在的位置设置一个读写断点，执行后发现，程序中断的位置的函数调用流程为：

注意在CCssDocumentLayout::GetPage的调用中，程序没有像发生异常那样调用CLayoutBlock::BuildBlock，而是调用了Ptls5::FsUpdateBottomlessPage，并且最终调用了CTextBlock的析构函数，在执行完析构函数之后，CGenericElment所在的CTextBlock的空间就释放了：

没有了设置offsetParent的语句，程序直接到达设置innerHTML的部分，此时查看CGenericElement的CTreeNode：

可以看到Char Format和Fancy Format的位置是-1，而如果有设置offsetParent的操作，这时这里应该不是-1。除此之外，CTextBlock的部分也是空的。这点之前也提到了，设置offsetParent会让IE重新对DOM树进行渲染，并构造相关的CTextBlock结构。

但是继续往下执行，我发现CTreeNode这里的空间直接被释放了？？？在IDA中仔细检查相关代码，在3.4.5追踪Fancy Format的时候，贴过函数调用流程，CTreeNode::VoidCachedNodeInfo查看了Char Format的数值，向前回溯，到达CTreeNode::PrivateExitTree函数：

有一个if语句，如果通过，会调用CTreeNode::Release函数：

这个if语句检查的是CTreeNode的倒数第三个DWORD，在此例中，即数值为0x08的字节。如果你查看一下之前的贴图，发生异常的情况下，这里的数值是0x18。

这里做个计算：

如上，可以看到两种情况的走向完全不同。

这个字节的数值在之前分析offsetParent的时候并没有注意，所以这次要在此调试一下，在这里设置一个读写断点，看看设置offsetParent是在什么时候对这个字节进行了修改，这个字节又有什么意义。

继续执行，会先到达CElement::ComputeFormats，没有重要操作，继续执行，到达这里：

上面的函数调用流程和3.4.4小节中，在CTreeNode中的CTextBlock指针那里设置断点时得到的函数调用流程十分接近，在IDA中查看，这个操作就在设置CTextBlock指针操作的后面几步。

再看一下这个函数的代码：

和上面的CTreeNode::Release函数中的计算看起来很相似，如果你仔细观察一下它的计算的话，其实CTreeNode::Release函数是在做一个-8操作，而CTreeNode::AddRef是在做一个+8操作。

所以CTreeNode的倒数第三个DWORD应该是这个CTreeNode的引用计数，默认有一个引用，指CElement中存储的那个CTreeNode指针，之后每增加一次引用，数值增加8，如果计数到达0，就会对这个空间进行释放。

鉴于执行完f0.offsetParent=null;之后，CGenericElement这个计数值从0x8变成了0x18，所以应该是增加了两个引用。

我猜测这里引用的增加和element_array有关（不一定正确）。因为：

目前程序断在了CTreeNode::AddRef，步进执行完这个函数，引用增加一次，数值增加8，此时数值是0x10。如果这个时候检查element_array中的内容：

如果继续F5执行，程序还会断在这里，执行完这个函数，再次查看element_array：

所以到这里就可以得出结论了，设置offsetParent的操作让IE对DOM树进行了渲染，形成CTextBlock，并在CTreeNode中添加其地址，增加CTreeNode的引用数。而清空innerHTML的时候，对于CTextBlock的操作存在问题，并没有清除element_array中的内容，引用数只减少了一个数值，导致对应的CTreeNode的空间没有被释放。

删除了f1.appendChild(document.createElement('table'));这句代码之后，设置好断点，然后让程序一直执行到达CElement::put_innerHTML函数，观察此时和CGenericElment有关的数据，会发现element_array中的数据变化很明显：

原本在存在table元素的时候，这里面应该只有四组数据，包含f2和CGenericElement。

现在还不知道这种变化有什么影响，继续向下执行，会发现直到垃圾回收之前，数据都没有什么太大的变化。垃圾回收之后，也之后CElement的空间被释放了，CTreeNode的空间仍旧存在，那么问题应该处在脚本执行之后的渲染阶段。

我在element_array中，CGenericElement所在的位置设置了一个读写断点，然后继续执行：

所以现在位于SLayoutRun::Clear函数，是在做什么清除吗？再看一下element_array中的内容：

前面几项竟然都被清除了！！

暂停一下，做一个整理，这篇文章我一共贴了两张图，如果你回过头去看第一张，会发现各个元素的CTreeNode结构中，记录CTextBlock的位置，f0、f1的CTextBlock和f2、CGenericElement的CTextBlock值是不一样的，而如果没有table元素，就像上面显示的，所有元素都在同一个element_array中了。

在调试分析offsetParent的时候，我们说IE在设置完offsetParent之后会对DOM树进行渲染，并构造相应的CTextBlock，这个说法其实不太准确，不是“构造”，而是更新。而在脚本全部执行完之后，在此渲染的时候，IE同样会更新CTextBlock。就像上面有一些清除操作。

接下来要仔细看一下在渲染前后，element_array的变化情况，还是回到会产生异常的那个poc脚本，因为比较好定位，最后一定会结束在异常状态。

可以看到在存在table元素的时候，有两个不同的element_array，而且保存在不同的CTextBlock中。接下来继续执行直到发生异常：

f0, f1对应的element_array所在的空间已经被释放了，如果检查一下对应的CTextBlock结构，会发现其中保存的element_array地址已经变了：

可以看到f0, f1对应的element_array内容进行了更新，现在里面只有f0和hr元素了。而f1在另一个element_array中：

唯一的问题就在于之前f2和CGenericElement所在的element_array的空间并没有被释放，仍旧存在：

所以现在可以得出结论了，table元素导致生成了两个CTextBlock，存在两个element_array，在脚本结束后对DOM树进行渲染时，更新CTextBlock的操作存在问题，并没有对第二个CTextBlock进行更新。最终导致了对已释放空间的访问。

到此为止，做一个总结：

创建table元素

形成两个CTextBlock，脚本执行后渲染更新CTextBlock的时候，只更新了第一个，保留了对已释放空间的引用。

设置offsetParent为null

更新CTextBlock，增加引用数，导致设置innerHTML的时候，不会删除CTreeNode的空间

清空innerHTML

清空f1和f2下面的元素，让之后的垃圾回收释放不再使用的空间

创建hr元素

让脚本执行后渲染DOM树时，能够重新遍历更新CTextBlock

根据文章一开始的分析，异常发生前执行的代码是：

现在我们已经知道，ecx寄存器中保存的是CGenericElement的CElement的地址，但是这块空间已经被释放了。所以如果能够想办法，在程序执行到这段代码之前，覆盖这块已经释放的空间，就有机会做到漏洞利用。

空间释放的操作发生在垃圾回收函数的调用中，所以覆盖操作要在垃圾释放之后。《漏洞战争》中介绍了t:ANIMATECOLOR元素，因为这个元素可以任意设置大小和内容，十分适合用于此次漏洞利用。

t:ANIMATECOLOR：
Changes the color of an object over time.

VALUES Attribute | values Property：
Sets or retrieves a list of semicolon-separated values of an animation.

由于代码中，获取的是偏移为0x70处的虚函数，所以t:ANIMATECOLOR要设置0x70的长度，最后的四个字节设置为shellcode的地址。

t:ANIMATECOLOR元素中的values保存的是指针，指向每个按照分号分隔后的字符串。因此values值中包含的分号个数就控制了程序在分配空间时的大小。而exploit代码中按照原本CGenericElement的CElement空间大小设置了values的大小，这种情况下系统肯定会优先选择大小完全一样的堆块空间分配给它，也就正好命中了已释放空间的地址。

！！！
！！！
！！！

注：CGenericElement的空间大小是0x38，即十进制的56。56/4==14。
在上面的代码中，依靠循环在animvalues后面添加了13个;red，所以一共就是14个值，正好对应。

一开始我没明白虚表指针是怎么设置的，书中写的是“用第一个分号前面的字符串覆盖虚表指针”，也没理解什么意思。

后来发现自己把最终animvalues的值看错了，又跟着调试了一遍上面的代码：

断点的设置还是跟之前都一样，开始执行之后就能获得各个元素CElement和CTreeNode的地址，执行到垃圾回收之后，就在CGenericElement的CElement地址处设置一个写断点，程序中断后看一下函数调用流程：

所以空间的分配应该是在mstime!CTIMEAnimationBase::put_values这个函数中，程序在设置t:ANIMATECOLOR的values的值的时候还会分配一个新的空间，而不只是复制一个指针值，这解决了我的一个疑问，我一开始认为代码中为animvalues赋值的时候就已经做了空间的分配。

回退一下，这次在mstime!CTIMEAnimationBase::put_values设置断点，然后逐步调试，这里不再贴出调试过程，直接对应到IDA中的代码，给出注解：

上面代码中的循环结束之后，原本的已释放空间数据如下：

可以看到已经被分割后字符串指针代替了。007335b8会被当成虚表指针。

总的来说，这次的漏洞分析让我在IE调试上学习到了很多，也了解到了很多IE底层的知识，而且极大地锻炼了自己的耐心。自认为对于CVE-2013-1347漏洞，文章里分析的已经很透彻了，也发现了一些书中没有提到的细节。

至于UAF漏洞利用，原理也算是清楚了，这次的漏洞和我在上周示例代码遇到的双重释放导致的UAF差别很大，上周的异常是由于多重释放时堆块大小的计算出现问题，导致访问超出范围，现在看来这应该不是普遍会遇到的UAF的情况，但是整个调试经历，异常原因的分析也很有趣。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课