这是《漏洞战争》里面分析的第二个栈溢出漏洞，虽然对于栈溢出这个概念本身已经很熟悉了，但是在分析这个漏洞的时候，书中介绍了如何使用Metasploit生成POC样本，以及Windbg调试的一些内容，我对于这些都不算特别熟悉，因为对我来说收获很大。这篇文章也会在这两方面有所介绍。

除了上面这两点，平时在工作中也会遇到好多RTF格式的漏洞利用病毒文件，虽然利用的可能并不是同一个漏洞，但是通过这个漏洞学习，相信也能够对其他RTF格式漏洞利用有所了解。

该漏洞存在于Microsoft Office XP SP3、Office 2003 SP3、Office 2007 SP2、Office 2010等多个版本中，由于Open XML文件格式转换器在处理RTF中的"pFragments"属性值时，没有正确计算属性值占用的空间大小，导致了栈溢出漏洞的发生。

以下说法可能和官方术语不符，只是为了理解。

RTF(Rich Text Format)文件中的内容可以分为内容单元和控制单元两个部分，软件读取RTF文件的时候，根据控制单元的内容设置对应内容单元的格式与位置，显示在文档中。

下面示例说明：

上面这个文件的显示结果是这样的：

RTF文件由头部(header)和文档(document)两个部分组成<File> '{' <header> <document>'}'：

可以和上面的示例文件内容做对比，对应关系还是蛮明显的。

这次分析的漏洞产生的原因是Open XML文件格式转换器在处理RTF中的"pFragments"属性值时，没有正确计算属性值占用的空间大小，那么这个pFragments属性值是怎么回事呢？

RTF文件中可以插入图形，图形在RTF文件中的格式如下：

其中{ \spp { \sn .......... } { \sp .............. } }是这个图形的属性组，spp是shape properties的缩写，sn表示属性名称，sv表示属性值。

而pFragments就是其中的一个属性名称，它是一个数组结构，表示图形的可选附加部分，列出了图形的所有碎片。

软件版本：Microsoft Office 2003 SP3

现在已经弄清楚了RTF的格式以及pFragments的含义，由于这个漏洞不像之前分析的漏洞一样已知是哪个DLL文件（我甚至都不知道是不是有这么一个DLL文件）中存在问题，因此无法静态分析，只能直接开始调试。

输入msfconsole进入msf之后，首先要搜索找到相关的脚本，书中提供的命令是search cve-2010-3333，我是用的是msf6，没有成功，后来使用了关键词pFragments：

接下来使用use指令指定exploit，使用info查看exploit的具体信息：

可以看到target的第六项是6 Crash Target for Debugging，使用set指令选择第六个目标，然后exploit指令就可以生成我们需要的PoC文件了。

这里使用的是Windbg，打开WINWORD.exe之后，使用Windbg附加到该进程，输入g命令让进程继续运行，然后打开msf.rtf文件，可以看到Windbg中的输出：

根据错误信息Access violation确定应该是esi或者edi所在的位置访问出错了，看一下这两个位置的值是什么，使用db查看字节数据：

看不出来有什么问题，esi处保存的应该就是复制的源字符串，要看一下所在内存的访问权限，使用!address命令可以显示内存信息：

原因出现了，edi所在的位置只有读权限，而现在程序在尝试向其中写入数据。

注意到错误信息中的esp寄存器值为esp=00123d98，esp处的数据为：

所以应该是程序在向栈中复制数据，由于没有判断数据长度，导致数据溢出到了不可写区域引发了异常。

一般来说分析到这里我会习惯找到出现问题的dll文件，定位到问题函数，然后直接到IDA里面进行静态分析，同时在OD的协助下完成对漏洞函数的理解，但是在《漏洞战争》这本书中，作者还在继续用windbg分析。为了熟悉windbg的使用，我也打算继续根据书中的流程进行分析。

由于一开始已经对漏洞进行了介绍，我们知道漏洞是在处理pFragments属性的时候发生的，所以合理怀疑上面windbg输出内容中，esp除的数据应该来自于pFragments属性内容，下面来验证一下。

看一下msf.rtf文件的内容：

由于文件过长，这里只截取了一部分数据，看起来不太一样，但是等一下，我们把pFragements的内容复制到十六进制区域再看一下：

目前不太确定msf.rtf中前面的11111111ACC8是什么意思，以及esp中前面的\Yd是什么意思，接下来调试的时候可以注意，但是剩余内容都是一致的。

确定了是哪一句指令出现异常之后，需要定位这句指令在哪个函数中，因为现在windbg已经执行到了异常发生的时候，整个栈帧已经被pFragments的数据覆盖了，无法获取有效信息，所以需要重新附加到WINWORD上，然后在异常发生地址0x30E9EB88这里下一个断点，继续执行：

此时还没有发生异常，栈帧中一切正常，使用kb指令显示调用堆栈及栈上的前三个参数：

由于缺少symbol文件，所以这个栈帧是有可能出错的，不过这里还是可以分析出来的。

第一个是当前函数栈帧，要看下一行00123e00 30f4a597 00123f88 00123f3c 00000000 mso!Ordinal753+0x306e，用ub指令查看指定地址之前的汇编代码：

漏洞代码出现在函数0x30F4CC5D调用之中，所以要再一次载入程序，在0x30F4CC5D下断点，然后继续执行

漏洞代码的地址x30e9eb88，之后使用F10单步调试，寻找位于该地址附近的函数调用：

一直单步到这里，有一个函数调用，函数地址是0x30E9EB62，和漏洞代码地址很接近，应该就是这里了，F11步入：

看一下这里的汇编代码：

需要注意esi、edi、ecx这三个寄存器的值，

所以数据要复制到0x123dc0。

这里经过第一步运算后ecx的值是0xC8AC，然后进行了右移两位（除以4）的操作，因为rep movs dword是以四个字节为一个单位进行复制的。

源数据所在地址为0x1104000C。

注意在上面我查看edi处的数据时，使用的是db edi-4的命令，可以看到\Yd已经在栈中了，所以这三个字符和数据的复制操作没什么关系，而ecx的值0xC8AC正是msf.rtf中保存的值，所以这两个字节用来保存pFragments的长度。

查看一下目前的寄存器情况：

数据复制的目标地址edi是0x123dc0，而此时栈帧基址ebp是0x123dd0，两者仅相差16个字节。所以如果想要覆盖返回地址，一共需要24个字节。

上面的分析流程和之前分析CVE-2010-2883还是有很大区别的，之前分析的poc文件是一个可以成功进行漏洞利用并攻击的样本，里面包含了shellcode。而这次则是从一个引发异常的样本出发，分析出漏洞位置以及如何进行漏洞利用。

分析到这里，已经可以看出这是一个很典型的栈溢出漏洞，可以把返回地址覆盖成jmp esp的地址，然后把shellcode放在pFragments中，实现漏洞利用。

想要构造POC文件，还需要进行一些静态分析，因为在执行完数据的复制之后，还要执行一些代码才能到达覆盖的返回地址处，如果只是简单的把返回地址和shellcode组合在一起，在到达返回地址之前，会首先触发异常。

注：我之所以能确定不能简单组合是因为自己试了一下，由于栈中原本的数据被覆盖，导致后面的函数执行出现异常，所以需要确定哪部分栈中的数据需要进行特殊处理。

根据一开始的错误信息：

使用lm指令显示模块信息（因为电脑了有两个mso.dll，所以这一步还是很有必要的）：

这里找到了mso.dll的位置，在IDA中分析。

漏洞函数的调用发生在sub_30F4CC5D函数中，漏洞函数本身只是在做一个数据的复制，并没有自己的栈帧，所以上面覆盖的返回地址是sub_30F4CC5D的返回地址。

在执行完漏洞函数之后，程序又调用了另一个函数，看下图：

调用了sub_30F4CB1D函数，如果这个函数返回值为0，就会达到函数结束的代码，

所以我们需要让sub_30F4CB1D函数的返回值为0。

在sub_30F4CB1D函数中：

所以要让第五个参数（第一个push到栈中的参数）为0。

对之前msf生成的poc文件进行修改，为了方便测试，使用的payload是在0day中提供的很简单的弹窗程序。

除此之外，注意到上面图片中最后的指令是retn 14h，所以需要在返回地址和payload之间添加20个字节的垃圾数据。

注意这个测试文件，返回地址后面的垃圾数据中，每四个字节的内容都不一样，这样可以更方便地确定是哪块数据需要特殊处理。

还是在0x30F4CC5D下断点，然后单步调试。在执行完漏洞函数之后，到达第一个push的位置

所以最后一个参数是0x94949494所在的位置了，为了再次确定，可以步入到sub_30F4CB1D函数中，执行到比较是否等于0的指令时：

所以我们需要把0x94949494修改为0。

最后得到的poc文件：

保存成rtf文件，双击打开，payload成功执行：

其实到这里整个漏洞利用流程就结束了，但是在《漏洞战争》中还提到了一些其他问题，在这里也进行一下总结。

在上面的实验中，我直接使用了书中提供的返回地址0x0026762f，这个地址在0ffice2003中是通用的，但是在office2007中则会触发异常。

其实我一开始安装的是office2007，结果实验结果和书里说的不一样，后来换成了office2003。现在再试一下office2007。

我遇到的问题就是msf生成的poc文件触发异常的位置不对。

在office2007的环境下打开poc文件之后

可以看到发生异常的位置不太对，这部分代码其实在书中后面也涉及到了，而且我在调试office2003的环境时也有碰到，

就是上图中“诡异的运算”那里。这个异常应该是我在上文提到的特殊位置如果不设置为0会遇到的异常。

如果把特殊位置设置成0，在office2007的环境下就会直接跳转到覆盖的返回地址那里。

所以msf生成的poc文件并没有将数据复制到不可写位置，如果查看一下触发异常时的栈帧情况：

可以看到数据是在0x11ffa4开始复制的，而复制的长度占用了两个字节，无论如何都无法写到0x130000，也就是不可写内存所在位置。

我也不清楚为什么结果是这样的，毕竟书上的环境也是office2007。

虽然没有正常触发异常，但是从结果来看漏洞还是存在的。

所以如果是在office2007的环境，可以通过覆盖 SEH handler地址的方式进行漏洞利用。

书中提到了可以使用msf的pattern_create和pattern_offset定位偏移量，Exploit编写系列教程（参考资料3）中对这个方法进行了介绍，我尝试使用里面介绍的方法对SEH handler的位置进行判断。

找到pattern_create.rb和pattern_offset.rb所在的目录，执行ruby .\pattern_create.rb -l 50000 > test.txt

这个时候得到的文件内容为：

注意到和msf生成的poc中内容是一样的，所以其实不需要自己再额外生成一个测试文件了，直接使用之前的poc文件也可以。

不过我还是又自己创建了一个rtf，test.rtf，要在010editor中把test.txt中的字符转化成对应的ascii值，然后替换成pFragments的内容。

回到windbg，同样的步骤，打开test.rtf，会在同样的异常位置暂停下来，再按一下F5让它继续执行，程序应该会尝试执行SEH handler（已经被覆盖掉了），由于覆盖的是随机地址，无法执行，所以会再一次到达异常：

注意到此时的地址0x37714836，这个地址就是覆盖之后的SEH handler地址。

执行ruby .\pattern_offset.rb -q 0x37714836 -l 50000（这个长度取一个比较大的值就行），查看这个地址的偏移，得到

应该就是5960，不然距离也太远了。

所以5960个字节之后的四个字节就是SEH Handler的地址，可以测试一下这个结论，在test.rtf中搜索36487137（这么看来直接搜索也可以，(lll￢ω￢)），替换成41414141，再次调试，输出：

确实断在了41414141这里，结论是正确的。

现在已经找到了SEH Handler的位置，按照书中说的，把这里的数值修改成0x0B0B2800，把前四个字节修改成0xEB06EB04，然后把shellcode放在SEH Handler的后面，再次打开test.rtf，成功得到弹窗：

其实书中对poc的结构已经进行了说明

框架是这样的

添加四字节长度信息，这里长度足够就可以

添加20字节垃圾数据，再加上四字节返回地址

添加16字节垃圾数据，再加上四字节的\x00

添加5912字节垃圾数据，再加上四字节EB06EB04和四字节0B0B2800，然后就是shellcode了。这部分内容太大，不再粘贴，完整文件见附件。

最终得到的文件在两个环境下都可以正常弹窗。

bp：下断点

ba：内存断点，ba access size [addr]

bl：列出已存在断点

bc：根据上面列出断点的标号，删除对应断点

g：继续运行

db：查看字节数据

db、dw、dd、dq：字节、字、双字、四字

da、du：ascii、unicode

dt：显示变量结构

!address命令可以显示内存信息

ub指令查看指定地址之前的汇编代码

uf：显示之后的汇编代码

r：查看寄存器

这次的漏洞分析和之前的流程都不同，从一个引发崩溃的poc文件触发，定位漏洞位置，判断返回地址的偏移，从而自己构造exploit文件。

除此之外，第一次没有使用OD进行分析，windbg的指令函数蛮强大的，就是不熟练，所以很多时候都会感觉不知道要干什么。

使用msf生成了poc文件，还接触了msf的pattern_create和pattern_offset，虽然这次没有用到多少功能，但是已经感觉到了它的便利性。

之前确认SEH Handler的位置都是在OD里面看栈上数据的标注，而这次则是在OD中让代码继续执行，查看EIP的值，其实过程中有很多不确定，但最终还是成功了，。

总体来说这次漏洞分析的过程还是比较顺利的，大致熟悉了Windbg的命令之后，我其实并没有完全跟着书上的流程走，而是根据当时的分析情况，从自己的疑惑出发逐步得到了最终结论。也发现了泉哥组织翻译的exploit编写系列教程，干货非常多，也要加入学习列表了。

感谢阅读~

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！