CVE-2012-3569：VMware OVF Tool 格式化字符串漏洞调试分析

0x01 简介

• VMware OVF Tool 是一个命令行实用程序，允许您从许多 VMware 产品导入和导出 OVF 包。在 2.1.0 - 2.1.3 之间的版本中存在格式化字符串漏洞，通过修改任意地址的任意数据，覆盖栈中的返回值，稍加利用就可以达到执行任意代码的目的

• 调试环境：Windows 7 + VMware OVF Tool 2.1.0、调试工具：OD、样本：poc.ovf

• 样本 poc + VMware OVF Tool 2.1.0 利用包下载（提取码：km7j）

0x02 OD 调试

• 安装完 VMware OVF Tool 之后，命令行进入其目录，之后运行 poc.ovf 脚本发现如下报错信息，由于了解格式化字符串漏洞的原理，所以可以看出在打印出 AAAA… 字符之后将栈上的空间信息也打印了出来，应该是通过 %x 打印出来的
  
  
• 由于格式化字符串漏洞的特殊性，所以在程序载入 OD 崩溃之后，可以选择使用智能搜索查找字符串 “Invalid value” 的方式来查找有漏洞的打印函数，这也是分析格式化字符串漏洞的通用方法
  
  
• 这个就是马上要压入并且要打印出来的字符串，再往下有两个 std::basic_string 函数，这里可以推断出打印的函数是 C++ 的 std 负责打印，而不是使用 C 语言的 printf 打印。经资料显示 std::basic_string 的作用是分配一些字符串，而 std::basic_ostream 则负责将这些字符串打印出来
  
  
• 由于知道了打印函数，所以直接在打印函数上下断点，待程序断在 “Invalid value” 处的时候，再激活断点运行，终于找到了在 std::basic_string 之后的 std::basic_ostream 打印函数
  
  
• 接着一直 F8 往下执行，直到发生崩溃，这样就可以结合崩溃处和样本中的数据推算出格式化字符的位置（也可以结合 IDA 分析，不过那样太麻烦）
  
  
• 经过几次尝试，发现到达此处的时候栈上的数据已经全部变为 ‘0’ 了，为什么会变为 ‘0’ 呢，因为 ebp 修改了 esp 的值，而 esp 是栈顶的指针；一般情况下 ebp 是不会被修改的，只有可能被格式化字符串给修改了
  
  
• 下面需要找到 ebp 是何时被修改的，结果是在 ovftool.00417280 函数的结尾把栈上的数据 0x 00180345 pop 到 ebp 中，记下此时栈顶的位置是 0x0018FF18
  
  
• 可以看到此时 ebp 的值为 0x00180345
  
  
• 然后看一下 poc 样本中的数据，由于格式化字符非常明显，所以一眼就能看到；在经过了若干个 %08x 的打印栈上数据之后，最后用了一个 %hn 将栈上的数据覆盖为字符串的长度
• 其中 %08x 的个数是 98 个，‘A’ 字符的个数是 26 个，%hn 之前的字符串长度为 (98 * 4 + 26) * 2 = 344 + 1 = 345，这里是宽字符打印
  
  
• %08x 是 98 个，这个的意思就是经过 98 个 %08x 打印之后才会修改栈上的数据，也就是上面修改 esp 的值，刚刚修改 ebp 的时候栈顶为 0x0018FF18，而 98 个 %08x 打印的栈上数据的长度为 98 * 8 = 0x310，再拿 0x0018FF18 - 0x310 = 0x0018FC08
• 再次运行到 “Invalid value” 字符串的位置查找栈地址 0x0018FC08，并且数据窗口跟随，往下寻找就会发现格式化字符的位置
  
  
• 此时 0x0018FF18 地址的值也被修改了
  
  
• 总结：CVE-2012-3569 巧妙的利用了格式化字符串漏洞，通过 98 个 %08x 定位栈地址，最后通过 %hn 将之前字符串的大小 0x345 覆盖栈地址值的高位，也就是刚刚的 0x0018FF18 的地址，做完了这些，那么被覆盖的值就会乖乖的弹出到 ebp 寄存器中，从而修改了 esp 的值…

0x03 利用

• 由于这个格式化字符串的可以将任意数据覆盖任意栈地址，那么利用起来就和栈溢出利用是相似的，就是覆盖函数的返回地址，通过 ROP 避开 DEP，寻找没有被 ASLR 保护的模块避开 ASLR 等等，相比其他漏洞利用起来还是非常容易的

• 参考资料：0day安全：软件漏洞分析技术 + 漏洞战争

CVE-2012-3569 的分析到此结束，如有错误，欢迎指正（天哪终于分析完了）