0x01 前言
- CVE-2011-0104 是 Microsoft Office 中的 Excel(没有打补丁的情况下)表格程序在处理 TOOLBARDEF 中的 Record 字节时没有对 Len 字段和 Cbtn 字段做过滤导致可以将任意大小的数据复制到任意地址的空间去,从而导致栈溢出漏洞。若攻击者通过构造恶意的 XLB 文件,受害者在未知的情况下打开恶意文件,受害者主机可能会被完全控制。到目前为止 CVE-2011-0104 漏洞还未收录在 metasploit 中
0x02 分析环境
- 虚拟机:Windows XP sp3 64 位操作系统,ASLR 处于关闭状态,便于调试(提取码:d3ho)
- 漏洞程序:Microsoft Office Excel 2003,版本:11.0.8211(提取码:woi9)
- 分析工具:OD,IDA(提取码:v0pt),Windbg(Windbg32,Windbg64),C32Asm(16进制分析文件工具,提取码:4sj8)
- 样本(POC):能够触发异常的 .XLB 格式文件(提取码:0oic)
0x03 定位程序异常
- 有了 POC 下面就可以开始定位异常,通用的做法是利用正宗的微软调试器 Windbg,先运行 EXECEL.EXE 文件吧
- 附加一个进程,一般是以附加的方式调试,也可以运行一个源程序再调试
- 找到刚刚运行的 EXECEL.EXE 程序的进程
- 运行,g 是运行的意思
- 这里使用打开文件的做法,如果使用的是拖入的方式加载文件,异常触发后会被 Windows 的异常处理给捕捉到,不利于调试,这里要注意
- 这个样本就是 POC 选中之后打开它
- Windbg 成功捕捉到异常,异常出现在 EXECEL.EXE 中,而不是通常的 .dll 文件中。这个异常表示在 0x30089ca1 这个地址,编译器读不出 0x51455047 这个地址,不知道这个地址代表什么。
- 一个正常的文件加载是不会出现这个异常的,那么为什么会出现这个异常呢,原因就是堆栈中的数据被覆盖了,原来可以读的地址被改成了 POC 样本中的数据导致不可读,0x51455047 这个数据极有可能是 POC 中的数据
- 最后看一下堆栈中的数据,都被覆盖了
0x04 OD调试
- 记下刚才程序发生异常的地址,在 OD 中断下
- 重新运行断在了异常处,暂且将这个异常函数称为 test_error 函数
- 此时堆栈的情况
- 下面需要跟踪堆栈,为什么需要跟踪堆栈呢,因为虽然知道异常点触发点,但并不知道堆栈中的数据何时被复制进堆栈的
- 为了搞清楚这个问题,首先需要定位栈顶位置和 test_error 函数入口点在哪里,但是目前堆栈中的数据被溢出覆盖了,没有办法定位怎么办,这里可以加载一个正常的文件
- 下图是加载了一个正常的文件并且定位到了异常点,注意此时 EBP 的位置
- 查看一下堆栈,利用 EBP 找到函数返回地址
- enter 一下返回值,断下这个函数,异常就出现在 EXECAL.30089b57 中也就是 test_error 这个函数
- 之后重新载入有漏洞的文件
- 运行到刚刚断下的函数后,F7 进入这个函数,运行到如下位置,此时函数已经开辟出 0x60 大小的栈空间
- 堆栈窗口如下图所示
- 在数据窗口查看堆栈信息,并且在栈底下内存写入断点
- F9 运行两次终于找到了这个污点,就是它将 POC 中的数据复制到了堆栈当中(其实找到查询堆栈复制信息的时候,还可以利用函数调试法来追踪,这里不做过多阐述)
- rep 是循环复制命令,计数器为 ecx,也就是 eax / 4 的值,此时 eax 为 0x300,可能是某个处理内存函数的参数
- 下断点后重新运行,F8 单步之后,堆栈空间被 POC 数据覆盖
- 和 POC 中的数据作对比,果然一模一样
0x05 结合 IDA 进行污点追踪,寻找出现问题的函数
- 在追踪之前需要知道污点函数的入口点,重新运行,断在了如下位置
- 利用堆栈进行查找函数,成功找到了污点函数的位置
- 下面就是污点追踪所需要的数据
地址 | 函数地址 | |
污点 | 0x3008942F | 0x3070DEA5 |
异常出发点 | 0x30089CA1 | 0x3008A85C |
- 直接利用 IDA 定位污点函数的地址 0x3070DEA5,翻译成伪代码(F5)
- 进函数看一下,发现了果然是 memcpy 这个函数处理内存的时候没有对数据大小进行过滤,0x300 就是这个函数的一个参数
- 来看一下函数的原型,IDA 中 a1 就是复制的目标地址,v7 就是拷贝的大小为 0x300
- 从 V7 入手(与 a1 分析原理相似,不做阐述),层层溯源,发现是这个函数传入的第三个参数
- 第三个参数又是 sub_3008945F 中获取的
- 进入这个函数看一下,发现这个函数是读取 POC 上的数据,下面来验证一下
- OD 载入,找到 0x3008945F 这个函数,下断点,返回值为 eax,所以看看 eax 何时变为 0x300
- 经过多次运行,找到了 0x300 这个数据
- 结合堆栈进行分析,发现确实是样本中构造的数据
- 逻辑图
0x06 总结
- CVE-2011-0104 漏洞归根结底还是利用了不安全的函数 memcpy,而函数的两个参数一个是复制源数据的大小,一个是复制的地址都是从 POC 中读取的,竟然没有做任何的过滤,最后导致了栈溢出的发生,之后发布的补丁也是对这两个参数做了过滤处理
- 参考资料:0day安全:软件漏洞分析技术 + 漏洞战争