CVE-2011-0104：Microsoft Office Excel 中的栈溢出漏洞调试分析

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安全：软件漏洞分析技术 + 漏洞战争