Word类型混淆漏洞原理分析（CVE-2015-1641）

今年4月份微软修补了一个名为CVE-2015-1641的word类型混淆漏洞，攻击者可以构造嵌入了docx的rtf文档进行攻击。

0×01前述

word在解析docx文档处理displacedByCustomXML属性时未对customXML对象进行验证，可以传入其他标签对象进行处理，造成类型混淆，导致任意内存写入，最终经过精心构造的标签以及对应的属性值可以造成远程任意代码执行。

该漏洞的利用细节以及shellcode目前网络上已经有不少分析案列。我个人比较感兴趣的还是如何定位到这个漏洞的触发点以及触发条件，因此本文中我将尝试如何一步步定位到这个漏洞。

0×02相关知识

在之前的相关文章中Ropchain和91ri-Leon的分析都是在POC中的堆喷射地址0x7c342404下断点调试，让程序直接走到shellcode中，再进一步分析整个利用过程，因此我最初的想法是尝试通过0x7c342404这个断点回溯，看能否找到关键函数，但实际尝试的时候发现这样做很困难（可能是调试方法的问题），不得已放弃。最近无意中看到WayneChin的一篇文章，他使用了一种简单粗暴的方法——直接对POC进行修改，然后通过crashword触发调试器的异常直接定位到造成漏洞的现场，果断尝试之。

实验环境：

OS:windows7
Wordversion：word2010sp2
wwlib.dllversion：14.0.7015.1000

0×03构造修改POC

既然要crashword，须对POC进行适当的修改。ropchain列出了该POC中各个主要模块，如下表所示。

通过分析发现POC文件为RTF文件，通过嵌入多个OLE对象构造的。上表中第一个是加载一个ActiveX/COM对象otkloadr.WRAssembly.1，通过这个调用MSVCR71.DLL（bypassASLR），其余三个分别是嵌入的docx文档：第一个docx，通过HeapSpray定位shellcode并ROP过DEP防护，第二个docx，则是触发漏洞的模块，第三个docx同样是HeapSpray。因此这里将触发漏洞的模块即第三个模块从原始POC样本中抽离出来，得到修改后的样本文件。

这里比较奇怪和WayneChin的提取的文件大小不一致，这是WayneChin提取前后的文件大小。

发现自己手动提取的文件和WayneChin差了100KB，应该是他的文件中还包含了一个OLE对象。不过这并不影响实验。

0×04crash

Windbg调试修改后的orignal_strip_first_second_fourth_ole.rtf文件，word果然crash了，现场如图所示。

当然为了避免偶然的情况发生，这个过程重现N次后，依然稳定crash。可以看到ECX总是指向地址0x7C38BD50，如果是完整的POC文件的话，[ecx]肯定是存在的，而且该地址应该存在于MSVCR71.DLL中，因为这个模块是漏洞利用时候所需的，验证一下，将MSVCR71.DLL模块添加至orignal_strip_first_second_fourth_ole.rtf中，即添加}，设置模块加载断点。

第一个模块加载完otkloadr调用MSVCR71.DLL，而地址0x7C38BD50位于MSVCR71.DLL中。将RTF样本中的docx文件提取出来利用winrar解压后，在路径..word下的document.xml文件中存在该地址的信息。

可以看到在smartTag的element中构造了0x7C38BD50，因此到这里大致清楚了是word在解析smartTag时存在错误造成漏洞，这是微软对smartTag所作出的解释。

大致意思就是这是一个智能标签，可对名字、地址等自动识别。先搞清楚Word是如何解析该标签的。

0×05解析过程

利用OD的条件断点功能，在crash位置前设置好断下的条件，这个条件断点的好处还在于重载之后断点不会消失，这样就能够准确的在我们所希望的位置断下，如图所示。

回溯几层即可找到word解析该样本中第一个smartTag标签的过程，如图所示

经过分析，v18指向smartTag对象，而*（v18+4）=0x7C38BD50，存储的是smartTag标签的element值，src=0xFFFFE696（十进制为4294960790）存储的是moveFromRangeStart的值，随后对这两个值进行一系列计算得到一个地址0x7C38BD74备用。过程如下

随后开始解析第二个smartTag，和解析第一个smartTag的过程一样，只是smartTag标签的element值此时为0x7C38BD68，moveFromRangeStart的值为0x7C376FC3（十进制为2084007875），计算出的地址为0x7C38A428，最后通过memcpy函数将0x7C376FC3的覆盖到地址0x7C38A428中。

因此0x7C38A428为虚表指针，覆盖前虚表中存放的虚函数指针为0x76DE6D07，指向kernel32.dll，现在被覆盖成了0x7C376FC3指向msvcr71.dll。

所以原本这个虚函数地址就被攻击者覆盖成任意地址，漏洞利用成功。

0×06补丁分析

微软针对该漏洞在word2010上发布的补丁编号为KB2553428，但是并没有发布sp1版的补丁，该补丁针对的是sp2版本，所以sp1版的office仍然存在漏洞。这里原本准备采用补丁对比工具Bindiff4.2进行比对，wwlib.dll文件大小为18M，尝试了很多次，一直无法比对完，如下图所示。

这可能是该软件的一个bug，最后无奈还是通过IDA来搜索关键指令定位补丁前后的关键函数，如下图所示。

通过补丁分析可以发现补丁前后的函数主要在处理smartTag前增加了校验环节。按照阿里的分析（http://www.freebuf.com/vuls/81868.html），传入的对象指针edi为customXML对象指针，而[ebx+48]则是当前的对象指针，在补丁文件中只有当前对象为customXML时才进行处理否则直接退出程序。而我们这里漏洞触发的原因是解析smartTag对象时造成的，因此这个漏洞是对customXML和smartTag对象没有加以区分造成对象类型混淆漏洞。

最后附上修改好的可以直接crashword的样本文件。

参考资料：

1.https://security.alibaba.com/blog/blog.htm?spm=0.0.0.0.qRNloh&id=31

2.http://blog.fortinet.com/post/the-curious-case-of-the-document-exploiting-an-unknown-vulnerability-part-1?spm=0.0.0.0.JDnFLI

3.https://www.91ri.org/14626.html

4.http://blog.ropchain.com/2015/08/16/analysis-of-exploit-targeting-office-2007-2013-ms15-022/

5.https://support.microsoft.com/en-us/kb/284927

6.https://technet.microsoft.com/zh-cn/library/security/ms15-033.aspx?spm=0.0.0.0.u4Cteo&file=ms15-033.asp