Fight For Freedom

08月 01

浅析CVE-2012-0158

0x01 漏洞简要
该漏洞是一个典型的栈溢出漏洞,在MSCOMCTL.ocx ActiveX控件中解析.DOC、.RTF、XLS等格式时,其数据流的反序列化过程中,MSCOMCTL读取大小字段流时,将它复制到一个固定大小的堆栈缓冲区。但由于没有正确检查边界,会导致栈溢出。

0x02 分析环境

windows xp sp3
office2007
windbg
IDA Pro 6.8


0x03 漏洞分析

   一. 定位shellcode

运行shellcode,通过监控发现了在C:\Documents and Settings\Administrator生成临时文件a.exe。定位shellcode的重点在于对关键函数的下断,这和经验有关。常见来说,直接定位溢出点比较麻烦,如果函数没有被编译器优化掉,我们可以对memcpy、strcpy等下条件断点。所以在这里采取对常见shellcode行为的函数下断点,其中包括GetTempPathA 或者 geitemppathw、CreateFileA、WinExec和CreateProcessA等。
于是直接对WinExec下断,bp kernel32!WinExec:
栈中第二个数为函数的参数,查看WinExec参数:
吻合我们实际观察到的情况。这里释放的exe和windows自带计算器的crc32比较,发现相同,表明a.exe应该是windows自带的计算器。
通过kb栈回溯,可以定位到溢出点。
根据回溯,大概判断出溢出点在下面箭头指示处。

      具体的溢出位置分析将会在后面讲到。继续分析,从上面我们可以判断出栈的大概位置,可以搜索shellcode的一些典型特征,比如滑板指令、jmp esp等等。于是用十六进制编辑器打开doc文档,搜索909090,在滑行区上方,发现了熟悉的jmp esp(0x7ffa4512处含有该指令)。(但此时在栈中搜索不到909090,!py mona find -type bin -b 100000 -t 130000 -s 90909090,可能之后的操作覆盖刷新了栈)

重新运行程序,对jmp esp处下执行断点ba e1 0x7ffa4512。
在前面的栈中可以发现0x7ffa4512及后面的shellcode部分。下面我们的目的是弄明白什么时候在该处发生了覆盖,被覆盖前的值是什么,程序正确的执行流应是什么。带着问题,继续往下分析。

  二. 找出溢出点

重新运行程序,在0x11aa84处下写断点ba w1 0x11aa84,同时在0x7ffa4512处下执行断点ba e1 0x7ffa4512为了看到详细信息,我们设置了异常通知,sxn -c "r eip; dd 0x11abfc|1" sse(这条指令在实际中好像没有啥作用。)

我们需观察在jmp esp前,程序所做的事。大概g了几百次,终于运行到符合要求的地方(要炸)。

很清楚地看到在jmp esp前有个赋值操作,判断这就是问题的出发点,因为覆盖才造成了程序控制流的改变。同时,需注意到该指令是在MSCOMCTL.OCX中,地址是固定的。

可以看到在0011aa84处已经被0x7ffa4513覆盖,回溯栈也可看到该变化,执行流已经发生变化。

因此,一定要重新下断点,先对MSCOMCTL.OCX下断,sxe ld:MSCOMCTL.OCX,之后在拷贝赋值语句处下端bp 275c87cb(注:不能直接对275c87cb下断,因为该地址执行需要加载在MSCOMCTL.OCX)。观察覆盖前的情况。
过了这几次断点后,我们可以看到ecx突然变得很大,表明真正的覆盖开始了。仔细观察esi中i的内容。在这条拷贝赋值指令中,我们可以看到它从esi拷贝了大概2000多字节到edi栈上。
此时,esi处已布好shellcode。
我们还可从上图中看到,栈上0011aa84之前的内容为275e701a,即原来的返回地址,我们到它正常的执行流上去观察。kb可看到:
由此经过简单分析,在回溯栈的过程中,可发现在call调用MSCOMCTL!DllGetClassObject+0x41c83 (275c89c7)时改变了程序的执行流。
由于在MSCOMCTL.OCX中的函数地址加载进程序后地址不会变,于是静态分析,在ida中可看到具体函数,按g,跳转到275c89c7,再F5,如下:
再跟进sub_275C876D,其中最主要的还是qmemcp拷贝函数。
qmemcpy,由src指向地址为起始地址的连续n个字节的数据复制到以dst指向地址为起始地址的空间内。大体上来看,是因为dwBytes判断错误,可以越界覆盖,致使栈溢出。然而具体的payload在整个解析流程的情况并未分析。


0x04 简单总结

对比网上其它同学的分析方法,一开始也是对shellcode行为下断,比如gettemppatha等,再一步步分析猜测其行为;同时,也搜索shelllcode的一些特征进行快速定位。之后要分析出跳转点,通过崩溃现场回溯堆栈调用。基本通过上述方式可以确定溢出点,但最关键的还是下断点,下好断点可以省很多时间和精力。

参考:
CVE-2012-0158简单分析报告.doc
cve-2012-0158分析笔记.pdf

标签:none

还不快抢沙发

添加新评论

captcha
请输入验证码

最新文章

最近回复

  • L_AnG:友链第一个居然是那个傻逼熟人,无语无语
  • lynahex:拜大佬
  • cdxy:师傅好
  • lynahex:十分感谢解惑,特别是解决问题的方法。
  • ld:1. 搜索CVE-2016-0701 进入 https://cv...
  • lynahex:好的。
  • xdxd:友链已加~~~希望有机会多多交流~~
  • lynahex:恩,重测了下是可以的。可能当时一些危险函数被我禁掉了。 thx
  • 过客:虽然博主文章过了好久了,本地system测试还是可以执行的
  • 友情链接

    分类

    其它