这次分析了CVE-2012-3569 ovftool.exe中的格式化字符串漏洞。之前使用示例程序详细分析过应该怎样利用格式化字符串漏洞（参考资料2），而针对该漏洞，《漏洞战争》中并没有进行详细分析，因此我几乎是从头到尾按照自己的思路独立完成了这个漏洞的分析以及利用，其中漏洞利用部分又占据了比较大的篇幅，因此对于格式化字符串漏洞在实际中的利用方式有了更深刻的了解。

WinXP sp3 简体中文版

VMware OVF Tool 2.1.0-467744 安装包书籍配套资料中有提供

使用ovftool.exe打开poc.ovf文件，得到输出的报错信息：

在错误窗口选择调试选项，Windbg的输出：

可以看到eip的值为0，同时栈中的数据已经清零。

由于漏洞发生在栈上，因此使用页堆功能无法定位异常发生位置，可以根据上面命令行中输出的错误信息进行定位。

使用IDA打开ovftool.exe，搜索字符串“invalid value”，得到：

根据错误信息的格式，可以确定是第二个结果。找到该字符串的引用位置之后，发现这里调用了std::string的构造函数，所以这里引用该字符串只是为了构造一个string对象，用于之后使用。

将该函数重命名为make_error_string，然后在windbg中，重新调试，并在字符串的引用位置设置断点。

使用Open Executable打开ovftool.exe，并设置相关参数，中断后在4B0434的位置设置断点，然后继续执行，在这里设置一个快照：

单步之后，eax的位置存储了字符串地址：

因为已经确定这是一个格式化字符串的漏洞，再加上输出的错误信息，猜测可能就是在输出这个错误信息的时候，对栈进行了破坏，所以要尝试定位输出函数的位置。

尝试1

最初我尝试在02dfce90和006c2978设置内存访问断点，但是失败了，设置好断点之后继续执行，程序直接到达了eip为0的位置。

尝试2

我看了一下书中的方法，内容并不多，只是说使用单步跟踪找到了具体位置，但是具体应该根据什么细节确定当前位置为目标位置，书中并没有明确介绍。所以接下来我就自己发挥想象力了。

我想用Shift+F11的方式，逐步跳出当前函数，确定异常是在哪个函数里面发生的。结果跳出两次之后，程序直接到达了wmain函数。

如果在IDA中查看，此时已经到达了这里：

这个时候开始单步：

到这一步的时候，ebp的值为00120345，而esp的值为0012ff78，按道理来说ebp的值应该比esp的值大，这里显然不正常，而且ebp的数据为：

也就是说问题出现在sub_417280函数里，但是这个结论显然没什么用，因为大部分功能都在这个函数里，说了和没说一样。

但是换个角度来想，此时我们已经发现了ebp的值是不对的，那么这个ebp的值是哪来的呢？是在sub_417280函数里，进行pop ebp操作的时候修改的。也就是说，sub_417280函数里的某个操作对栈中的数据进行了修改，并覆盖了原本应该弹出到ebp中的数值，而且这个数值保存的位置就在sub_417280函数栈帧的ebp位置（因为执行的是mov esp, ebp; pop ebp的操作）。

所以接下来回到之前的快照，跳出一次，到达sub_417280函数中，然后在ebp的位置设置一个内存访问断点，检查程序是在哪个位置对这里的数值进行了修改。

跳出一次后，ebp中的数据：

注意到此时ebp中的数值还是正常的，我们在0x12ff50这里设置一个内存访问断点。

上一步指令为mov word ptr [eax],cx，正是这句指令修改了ebp位置的值。

由于此时栈帧被修改，查看函数调用的结果可能是不正常的，所以还是回到之前的快照，在上一步指令的位置设置一个断点，然后查看函数调用情况：

在函数调用情况的倒数第四个位置，看到了位于wmain中的返回地址，所以上一项就应该位于sub_417280函数中，继续向上看，在返回地址为0047ea37的这一项，程序调用了标准库函数，这里应该就是在执行输出操作，所以我们直接在IDA中定位地址0047ea37。

然后查看一下这个函数的伪代码：

所以ebp处的数值被修改，就发生在字符串输出的过程中。

关于格式化字符串漏洞如何利用，之前写过一篇文章：[原创]格式化字符串漏洞利用方法及CVE-2012-0809漏洞分析

先看一下poc.ovf文件的内容：

根据错误信息，程序就是在处理ovf:capacityAllocationUnits这个属性值的时候出现了问题，在尝试对属性值输出的时候，出现了格式化字符串漏洞。

因为在尝试对属性值输出的时候，属性值被当成了格式化字符串，所以输出的时候，由于%08x的影响，程序直接将栈中的数据dump了出来。

但是现在的问题在于，程序dump的是哪一块数据，或者说程序中具体是哪个函数在做真正的格式化输出。

在之前对格式化漏洞进行分析的文章中，实验程序使用C语言写的，要打印的字符串直接压入栈中，可以很清晰的看到栈中数据的结构，但是这次的程序是C++的，调用了operator<<来对字符串进行输出，传入的是this指针。所以乍一看很难确定格式化字符串输出的是栈中的哪块数据。

我尝试对输出的数据进行搜索，但是并没有搜索到，可能在调用operator<<返回的过程中栈中数据又有了修改。

所以需要进一步深入分析，确定字符串打印的时候，栈中数据的情况。

上面划掉的是我一开始尝试时采用的方法，后来发现不用那么麻烦。直接根据上面得到的函数调用流程在IDA中查看各函数的代码，在检查到：

这一行的时候，根据地址004b375f定位到函数sub_4B3700，该函数伪代码：

同时确定下一个调用的函数是sub_56B660，再看一下这个函数的伪代码：

注意到这个函数的参数了吗？还有其中的变量va_list va，然后它又进一步调用了v1 = (char *)sub_57CB80(0, a1, va);，这不就是printf的格式吗？不妨就将sub_56B660命名为my_printf。

接下来可以到windbg中验证一下了，在004b375a设置一个断点（调用my_printf的位置），执行到这里的时候，栈中的情况：

这里我贴出了很多栈中的数据，是为了方便和下面打印出来的数据做比较。

其中栈顶是第一个参数，查看一下其中的数据：

就是要打印的内容。终于看见了胜利的曙光，先在这里建立一个快照。然后直接步过看一下打印的结果（因为多次调试，此时的结果和本文开始贴出的结果不一致）。

对上面打印出来的数据进行一下整理，可以发现在连续的A字符之后，以四字节为单位对数据进行分割，最后得到的内容和上方得到的栈中数据是一致的。

再回过头来看一下Poc文件中提供的格式化字符串，其实包含了26个A字符，98个%08x字符串，因此程序在这里会打印出98个四字节数据，而第99个四字节数据就是栈中的0012ff50，也就是2.2.2小节调试时得到的ebp的位置。

在2.2.2小节中，根据调试结果，我们已经得到了程序写入的数值（已打印字符数）为0x345，那么这个数值是怎么来的呢？

在连续的A字符之前，还包含字符串 - Line 14: Invalid value '，注意前面的空格，这部分内容就有27个字节，所以到%hn为止，已打印的字符数应该是27 + 26 + 98 * 8 = 837，换算成十六进制，就是0x345。

所以到目前为止，我们已知在ovf文件中，如果ovf:capacityAllocationUnits属性值内容出错，会直接被函数sub_56B660即my_printf函数打印出来。因此将该属性值内容构造成格式化字符串的形式，就会触发格式化字符串漏洞。

经过上一小节的调试和分析，我们确定了发生格式化字符串的打印操作时，输出的数据位于栈中的哪个位置；经过之前文章中对于格式化字符串漏洞的利用分析，也知道该如何利用格式化字符串漏洞。

所以接下来需要针对此次漏洞，详细分析栈中数据内容，确定该如何利用这个漏洞。

在poc.ovf这个文件中，ovf:capacityAllocationUnits属性值的设置导致最后程序执行到了0x000000，因为它构造的格式化字符串导致在字符串输出之后，修改了ebp位置的值，这样在函数退出时执行：

而如果想要完成漏洞利用，我首先想到的是直接修改到返回地址。

可以看一下被打印出来的栈中的数据，返回地址在栈中，所以它一定是0x0012f???的格式：

在poc.ovf中，选择写入的是最后一个0x0012ff50这个地址，而返回地址位于0x0012ff54这个位置，如果你和函数调用流程中一些列的ChildEBP值作比较，会发现栈中数据会命中多个ChildEBP，但是没有命中ChildEBP+4的。

所以目前看来，如果想要漏洞利用，还是要使用和poc.ovf中一样的方式，覆盖ebp的位置。而且既然之前已经对poc.ovf中的属性值进行了简单分析，有了一定了解，那么最好就保留原始格式不变，仍旧覆盖0x0012ff50这一位置，即属性值中%x的个数保持不变。

因此现在唯一能做的就是修改前面连续的字符A的部分（或者是%08x中的数值），可以调整字符的个数，从而改变写入0x0012ff50的数值大小。

需要注意到，对于0x0012ff50的修改，只会修改其低位的两个字节，0x0012ff50处原本保存的就是栈帧基址，所以高位字节0x0012这个数值是不变的。

我们希望在修改之后，新的数值0x0012????作为新的栈帧基址（之后变成栈顶），其偏移四字节的位置可以作为返回地址，改变程序的执行流程。

现在能想到的就是找到属性值在栈中的位置，将0x0012ff50覆盖为属性值在栈中占用的空间地址，这样我们就可以控制偏移四字节位置的数值了。

可以在0x00120000~0x0012ffff这一范围内搜索一下：

可以看到栈中确实存在属性值中的内容，如果检查前面的数据，可以看到这一部分空间保存的就是ovf文件的内容。

但是问题在于，怎么保证这个地址是不变的，毕竟这是栈中的一片空间，如果字符串长度发生变化，它的偏移地址有极大可能会发生变化。

然后我想到了之前Exploit编写系列教程学习笔记中学习到的方法，使用pattern_create.rb及pattern_offset.rb生成capacityAllocationUnits属性值内容，确定在属性值足够大的时候，是否能找到一个相对固定的偏移地址，就像是堆喷射中的0xC0C0C0C0那样。

注：我这里的想法是错的，关键不是在于找到一个固定的偏移地址，而是找到一个漏洞能够覆盖到的地址，后面的实验发现漏洞无法覆盖全部的0x120000~0x12ffff范围

一开始生成一个长度为10000的测试字符串，并用它替换原属性值中连续的A字符串，重新进行调试，在004b375a设置断点（调用my_printf函数的位置）。

结果我发现在调试的时候，程序并不是一次性打印出所有的内容，而是每次最多打印4096个字符：

也就是说，在打印最后包含%08x在内的格式化字符串时，所谓的“已打印字符数”的最大值就是0x1000，所以最后写入0x0012ff50的时候，可以写入的数值范围为0x00120188 ~ 0x00121000(最小范围是因为要保证有足够的%x)。

因此我们要保证属性值的内容最终能够保存在0x00120188 ~ 0x00121000这个范围内。

这么一看，我们上面得到的地址0012d4f3也没办法使用。

这次再搜索一下属性值中的内容所在的位置：

这次的位置在00116b47，小于最小范围，并且由于长度不够长，没有覆盖到期望范围。

那么要如何确定一个合适的长度呢？首先看一下栈空间的范围：

可以看到栈空间范围是0x00115000~0x00130000，肯定不能让属性值的长度把空间完全占掉，但是我们可以考虑一个比较大的值的情况，0x00121000-0x00115000=C000。但是这里并不是要让属性值的长度等于C000，因为每次程序会打印0x1000个字符，所以这里考虑保证最后的总打印字符数是C000。

在打印属性值之前，首先会打印长度为27字节的 - Line 14: Invalid value '，然后会打印非格式化字符串，即使用pattern_create.rb生成的字符串，然后会打印8*98个字节的格式化字符串部分，因此如果想要让总体长度为C000，需要生成的字符串长度为C000-1B-310=BCD5。

用新的测试文件开始调试，并在0057eaf5（设置0x0012ff50）的位置设置一个断点：

可以看到正在向0x0012ff50的低位写入0x1000，看一下0x121000这里的数据：

确实是属性值中的内容。

如果属性值的长度不变，这个偏移值应该是稳定的。所以目前为止我们已经确定了属性值的长度以及“已打印字符数”的数值。

接下来我们要保证0x00121000偏移四字节的位置，即原本的7Cb8，是正确的返回地址，比如说经典的jump esp指令的地址。

确定jump esp指令位置

注：这里要保证得到的地址在[30~7F]的范围内（这个范围可能不准，需要进一步测试），否则ovftool.exe可能会出错。

使用Exploit编写系列教程学习笔记提到的findjmp.exe程序找到jump esp指令地址：

选择倒数第三个0x7E48754C（经过实验ovftool.exe不会出错）。

确定替换位置

直接在生成的字符串中搜索7Cb8，结果找到了三个位置，为了确定是哪个位置的7Cb8会作为返回地址，分别把这两个位置的字符替换成AAAA、BBBB和aaaa，重新调试执行之后，程序跳转到了0x61616161：

因此可以确定第三个7Cb8的位置会变成返回地址，将其替换为jump esp的地址。

将返回地址的位置替换为jump esp指令地址之后，已经能够控制程序的执行流程了，接下来需要将shellcode替换填充到返回地址的后面，实现shellcode的执行。

使用msf生成一个弹计算器的shellcode，注意要排除\x00字符，同时选择x86/alpha_upper编码器，并设置ESP寄存器指向shellcode：

最后用生成的439个字节的shellcode内容替换掉返回地址后面的439个字节。

在命令行中使用ovftool.exe加载制作好的test.ovf文件，成功弹出计算器：

和其他漏洞相比，格式化字符串漏洞的分析过程其实格外地明确，因为它的原理是很单一的。关键点就在于要确定格式化输出函数的位置，而由于存在“输出”的过程，因此可以根据输出结果对代码进行初步定位。一旦确定了格式化输出函数的位置，就能够进行漏洞利用了。而关于漏洞利用的方法，之前也有了很详细的分析过程，因此此次的漏洞分析过程虽然走了一些弯路，但是总体上是一次比较流畅的分析过程。

在漏洞调试和利用的过程中充分实践了之前文章中学习到的分析方法，希望各位也能有所收获。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！