CVE-2017-11882简单分析报告-0xPoker's Blog

文件信息

文件名:test.doc(github生成器)
文件类型:doc
md5:d86c7300c0bfe626273b10086b1a0460

漏洞行为

CVE-2017-11882简单分析报告-0xPoker's Blog

可以看到word在打开之后执行命令cmd.exe /c calc.exe &AAAAAAAAAAAAAAAAAAAAAAA C

漏洞分析

启动时附加调试器方法:https://bbs.pediy.com/thread-247767.htm

修改注册表之后,在原来火绒剑处,能看到调用栈还是从WinExec开始的

CVE-2017-11882简单分析报告-0xPoker's Blog

断点下好之后,运行,确实断下来了。所以我们看一下执行的参数是啥。

CVE-2017-11882简单分析报告-0xPoker's Blog

确实,调用cmd运行命令calc,弹出计算器。

调用栈为:

00 0012f1cc 00430c18 0012f350 00000000 0012f1ec kernel32!WinExec
WARNING: Stack unwind information not available. Following frames may be wrong.
01 0012f210 004218e4 0012f350 0012f5e0 0012f7e4 EqnEdt32!MFEnumFunc+0x241b
02 0012f300 004214e2 0012f350 001f005a 00000001 EqnEdt32!FMDFontListEnum+0x650
03 0012f32c 0043b466 0012f350 001f005a 0012f5e0 EqnEdt32!FMDFontListEnum+0x24e
04 0012f454 0043a8a0 0012f5e0 0012f7e4 00000006 EqnEdt32!MFEnumFunc+0xcc69
05 0012f46c 0043a72f 00120008 0012f5e0 0012f7e4 EqnEdt32!MFEnumFunc+0xc0a3
06 0012f484 0043a7a5 00120008 0012f4ac 0012f5e0 EqnEdt32!MFEnumFunc+0xbf32
07 0012f4b4 00437cea 00120008 001ba2ec 00120000 EqnEdt32!MFEnumFunc+0xbfa8
08 0012f4e4 0043784d 001ba2ec 00000000 0012f5e0 EqnEdt32!MFEnumFunc+0x94ed
09 0012f548 0042f926 0012f560 0012f5e0 0012f7e4 EqnEdt32!MFEnumFunc+0x9050
0a 0012f578 00406a98 005a007c 0012f5e0 0012f7e4 EqnEdt32!MFEnumFunc+0x1129
0b 0012f5dc 76e504e8 001bf128 02d20570 00000202 EqnEdt32!AboutMathType+0x5a98
0c 0012f5f8 76eb5311 00406881 0012f7e8 00000002 RPCRT4!Invoke+0x2a
0d 0012fa00 76a2d7e6 001aebe8 001aa2a8 001b4aa0 RPCRT4!NdrStubCall2+0x2d6
0e 0012fa48 76a2d876 001aebe8 001b4aa0 001aa2a8 ole32!CStdStubBuffer_Invoke+0xb6 [d:\w7rtm\com\rpc\ndrole\stub.cxx @ 1590] 
0f 0012fa90 76a2ddd0 001b4aa0 001bad90 001bf470 ole32!SyncStubInvoke+0x3c [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1187] 
10 0012fadc 76948a43 001b4aa0 001bfb58 001aebe8 ole32!StubInvoke+0xb9 [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1396] 
11 0012fbb8 76948938 001aa2a8 00000000 001aebe8 ole32!CCtxComChnl::ContextInvoke+0xfa [d:\w7rtm\com\ole32\com\dcomrem\ctxchnl.cxx @ 1262] 
12 0012fbd4 7694950a 001b4aa0 00000001 001aebe8 ole32!MTAInvoke+0x1a [d:\w7rtm\com\ole32\com\dcomrem\callctrl.cxx @ 2105] 
13 0012fc00 76a2dccd 001b4aa0 00000001 001aebe8 ole32!STAInvoke+0x46 [d:\w7rtm\com\ole32\com\dcomrem\callctrl.cxx @ 1924] 
14 0012fc34 76a2db41 d0908070 001aa2a8 001aebe8 ole32!AppInvoke+0xab [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1086] 
15 0012fd14 76a2e1fd 001b4a48 001ab748 00000400 ole32!ComInvokeWithLockAndIPID+0x372 [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1724] 
16 0012fd3c 76949367 001b4a48 00000400 0019d3e8 ole32!ComInvoke+0xc5 [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1469] 
17 0012fd50 76949326 001b4a48 0012fe10 00000400 ole32!ThreadDispatch+0x23 [d:\w7rtm\com\ole32\com\dcomrem\chancont.cxx @ 298] 
18 0012fd94 7730c4e7 000a022e 00000400 0000babe ole32!ThreadWndProc+0x161 [d:\w7rtm\com\ole32\com\dcomrem\chancont.cxx @ 654] 
19 0012fdc0 7730c5e7 76949286 000a022e 00000400 USER32!InternalCallWinProc+0x23
1a 0012fe38 7730cc19 00000000 76949286 000a022e USER32!UserCallWinProcCheckWow+0x14b
1b 0012fe98 7730cc70 76949286 00000000 0012fec0 USER32!DispatchMessageWorker+0x35e
1c 0012fea8 004261b5 0012fed8 00000000 001721df USER32!DispatchMessageW+0xf
1d 0012fec0 0040e5bf 0012fed8 00000000 001721df EqnEdt32!FMDFontProtoEnum+0x429d
1e 0012fef4 0044ce8b 00400000 00000000 001721df EqnEdt32!MtInsituWndProc+0x5851
1f 0012ff88 76d93c45 7ffde000 0012ffd4 774237f5 EqnEdt32!FltToolbarWinProc+0x2d24
20 0012ff94 774237f5 7ffde000 774c4661 00000000 kernel32!BaseThreadInitThunk+0xe
21 0012ffd4 774237c8 0044cd40 7ffde000 00000000 ntdll!__RtlUserThreadStart+0x70
22 0012ffec 00000000 0044cd40 7ffde000 00000000 ntdll!_RtlUserThreadStart+0x1b

这次的栈似乎并没有很大的破坏,显示得比较完全。

CVE-2017-11882简单分析报告-0xPoker's Blog

能看到如果栈溯源的上层栈就是这个程序的,所以用IDA过去看看对应位置发生了什么。

CVE-2017-11882简单分析报告-0xPoker's Blog

找到对应位置之后能看到,公式编辑器MFEnumFunc+0x2415的位置直接就摆着一个WinExec,只要能溢出传入参数就是直接执行。

并且lpCmdLine来自于上层函数FMDFontListEnum+0x64b

然而这层函数明显不改调用到sub_430C00,也就是含有WinExec的函数

CVE-2017-11882简单分析报告-0xPoker's Blog

用静态找路径的插件,寻找之后也是确实没有,那说明溢出点就在这个函数的某个地方。

CVE-2017-11882简单分析报告-0xPoker's Blog

栈溯源找到的倒数第二函数应该是他,说明栈溢出发生在这里面。

CVE-2017-11882简单分析报告-0xPoker's Blog

函数中乍一看也是没有能溢出的地方的,能看到先对长度判断,然后将字符串传入一个函数sub_41160F

CVE-2017-11882简单分析报告-0xPoker's Blog

但是进去看到执行的功能其实就是strcpy并不是strncpy或者strcpy_s,这很容易就导致了栈溢出覆盖返回地址。

所以流程应该是通过这里读入的内容覆盖了返回地址为可执行WinExec的函数,并执行

CVE-2017-11882简单分析报告-0xPoker's Blog

CVE-2017-11882简单分析报告-0xPoker's Blog

溢出的内容就在这里了。