用的是泉哥的POC来调的这个漏洞
0x0 漏洞调试
Microsoft Office Open XML文件格式转换器栈缓冲区溢出漏洞
Microsoft Office 是微软发布的非常流行的办公软件套件。
基于Mac平台的Microsoft Office XP SP3，Office 2003 SP3，Office 2007
SP2，Office 2010，Office 2004以及2008版本，基于Mac 2011平台的Office，以及基于MAC平台的Open
XML文件格式转换器中存在基于栈的缓冲区溢出漏洞。远程攻击者可以借助特制的RTF数据执行任意代码。该漏洞又名"RTF栈缓冲区溢出漏洞"。
加载POC后，程序中断在如下所示位置
(8a0.b70): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0000c8ac ebx= ecx=0000019b edx= esi=1051c24c edi=
eip=30edf864 esp=00123d98 ebp=00123dd0 iopl= nv up ei pl nz na pe nc
cs=001b ss= ds= es= fs=003b gs= efl=
mso!Ordinal1488+0x29fd:
30edf864 f3a5 rep movs dword ptr es:[edi],dword ptr [esi] es::= ds::1051c24c=4c36744c
此时若是查看栈回溯会发现得不到正确的结果，判断应该是栈被覆盖导致栈回溯被破坏得不到正确的结果，于是对mso!Ordinal1488+0x29fd:位置下断。重新执行程序发现可以正常的得到回溯结果了。栈回溯结果如下
:> kp
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
00123dd0 30f0f3cb mso!Ordinal1488+0x29fd
00123e00 30f0f359 mso!Ordinal901+0x2a3c
0012404c 30d4d762 mso!Ordinal901+0x29ca
30d4d70b mso!Ordinal4925+0x53
30d4d47d mso!Ordinal5148+0x36
0012407c 06270b10 mso!Ordinal4783+0x12f
06270b48 0x6270b10
062709f8 0x6270b48
30dd112c 0x62709f8
0012408c mso!Ordinal2940+0x1588c
可以看到本段函数是由mso!Ordinal901+0x2a3c（30f0f3cb）调用而来，对30f0f3cb函数进行查看发现并不是调用到本函数的，而是调用了 sub_30F0F422。如下所示
:> ub 30f0f3cb
mso!Ordinal901+0x2a28:
30f0f3b7 23c1 and eax,ecx
30f0f3b9 push eax
30f0f3ba 8d47ff lea eax,[edi-]
30f0f3bd push eax
30f0f3be 8b4508 mov eax,dword ptr [ebp+]
30f0f3c1 6a00 push
30f0f3c3 ff750c push dword ptr [ebp+0Ch]
30f0f3c6 e857000000 call mso!Ordinal901+0x2a93 (30f0f422)
跟进sub_30F0F422里面也没有发现有直接调用30edf864所在函数的语句。用ida加载MSO.dll文件，发现30edf864所在的函数被IDA识别为数据，自行创建函数之后求交叉引用发现此地址被置于如下所示的数据表中，推测是某一个对象的虚表？
.text:30DA6114 dd offset sub_30EDF83E
总之发现了30f0f422对30edf864所在函数的调用关系。
分析30edf864所在的sub_30EDF83E函数可以看到，所执行的rep movsd指令的edi（复制的目的地址）为2号参数。复制的次数为 (*(参数1+8)&65535)/4 。复制的源地址为 *(参数1+8)&65535*参数3+*(参数1+16) 。看起来很奇怪是不是我也觉得很奇怪，但是觉得可能是某个对象的this指针。我们先对mso!Ordinal1488+0x29fd（30edf864）下断，重新运行程序断在这里，这时可以看到ecx的值为0x322b如下所示。我们知道这个大小意味着相当的大（0x322b=13099,13099x4=52396）,共52396个字节。
:> r
eax=0000c8ac ebx= ecx=0000322b edx= esi=1051000c edi=00123dc0
eip=30edf864 esp=00123d98 ebp=00123dd0 iopl= nv up ei pl nz na pe nc
cs=001b ss= ds= es= fs=003b gs= efl=
mso!Ordinal1488+0x29fd:
30edf864 f3a5 rep movs dword ptr es:[edi],dword ptr [esi] es::00123dc0=ffff0000 ds::1051000c=
无论如何栈也是承受不了这样的大小的。那么到底能承受多少呢？我们来看下。
.text:30F0F422 var_10 = dword ptr -10h .text:30F0F44B lea ecx, [ebp+var_10]
.text:30F0F44E push ecx
.text:30F0F44F mov ebx, 5000000h
.text:30F0F454 push esi
.text:30F0F455 mov [ebp+var_C], ebx
.text:30F0F458 call dword ptr [eax+1Ch] //调用sub_30EDF83E
由上面可以知道，复制的目的地址就是var_10，一个sub_30F0F422中的4字节的局部变量。试图往4个字节中拷贝个字节，这样肯定是会溢出的了。我们进一步看一下栈的情况
:> dc edi
00123dc0 ffff00ff 00e4ffff ................
00123dd0 00123e00 30f0f3cb 00123f3c .>.....<?......
00123de0 ffffffff 01280b28 ........(.(. D..
00123df0 0012408c 00124e38 001240b0 .@..8N...@......
00123e00 00123fe4 30f0f359 00123f88 00123f3c .?..Y...?..<?..
00123e10 01280b28 0012408c ....(.(..@.. D..
00123e20 ffffffff ffffffff ffffffff ................
00123e30 ....... ........
:> kp
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
00123dd0 30f0f3cb mso!Ordinal1488+0x29fd
00123e00 30f0f359 mso!Ordinal901+0x2a3c
0012404c 30d4d762 mso!Ordinal901+0x29ca
30d4d70b mso!Ordinal4925+0x53
30d4d47d mso!Ordinal5148+0x36
0012407c 01280b10 mso!Ordinal4783+0x12f
01280b48 0x1280b10
012809f8 0x1280b48
30dd112c 0x12809f8
0012408c mso!Ordinal2940+0x1588c
可见最多达到16byte时会覆盖ebp，然后是返回地址。
0x1 漏洞分析
我们在前面看了一下漏洞触发的原理，但是漏洞为什么会存在还并没有搞清楚。我们回过头来看一下漏洞描述可以知道这是对rtf文件的解析不正确所导致漏洞。那么我们来看下拷贝的东西是什么
:> db esi
1109000c ba 1e 1d d9 c7 d9- f4 5e c9 b1 ........t$.^)..
1109001c ee fc 0e - 6a f0 c3 e3 fb ...1V..H.j.....p
1109002c e1 de- b2 dd ..r.%.....a...'&
1109003c 2e ef 1e d6 - af d6 2a da b1 aa ...I...d...*...
1109004c 0f fb d3 e1-ad 8c 6e 1f b6 b9 ....BS.....n...
1109005c 9c b7 6d 9c cf fd- 7a 2d c1 f1 5c d5 ..m9....iz.-..\.
1109006c 5d 7d e4 be bd af-cb 2e 1a ba i]}...A..v1..G..
1109007c ae 6f c1 - 6b 2d fa b...oT...#9k-..
在poc文件中搜索一下，如下图
咦，acc8这个数有点熟悉啊
:> g
ModLoad: 05da0000 05f41000 C:\Program Files\Microsoft Office\OFFICE11\GdiPlus.DLL
Breakpoint hit
eax=0000c8ac ebx= ecx=0000c8ac edx= esi=1051000c edi=00123dc0
eip=30edf861 esp=00123d98 ebp=00123dd0 iopl= nv up ei pl nz na pe nc
cs=001b ss= ds= es= fs=003b gs= efl=
mso!Ordinal1488+0x29fa:
30edf861 c1e902 shr ecx,
注意看ecx，明显是信任了rtf文件的给出的大小而没有进行自己的验证，而那些.doc的样本其实就是rtf文件改了一下后缀名，其实还是按照rtf进行解析的。搞定！
ps:win7通用的jmp esp 7ffa4512