格式化字符串漏洞利用 五、爆破
五、爆破
原文：Exploiting Format String Vulnerabilities
译者：飞龙
日期：2001.9.1
版本：v1.2
当利用这种漏洞，例如缓冲区溢出或者格式化字符串漏洞时，它通常会失败，因为没有当心最后的障碍：将所有偏移弄正确。基本上，寻找正确的偏移意味着“将什么写到哪里”。对于简单的漏洞，你可以可靠地猜测正确偏移，或者爆破它，通过一个一个尝试它们。但是一旦你需要多个偏移，这个问题就指数增长，它变得不可能爆破。
在格式化字符串中，只有你在利用守护进程，或任何只给你一次尝试机会的程序时，这个问题才会出现。一旦你拥有多次尝试机会，你就可以观察格式化字符串的响应，虽然不足以发现所有必要的偏移。
这是可能的，因为在完全控制它只花钱，我们已经可以有限控制目标进程：我们的格式化字符串已经告诉了远程进程要做什么，让我们能够窥探内存，或者测试一定的行为。
因为这里解释的两种方式差异很大，它们会单独解释。
5.1 基于响应的爆破
tf8 在最流行的格式化字符串利用（wu-ftpd 2.6.0）中 观察并利用了打印出来的格式化回应。它使用这个回应来判断距离。
我和 smiler 深入发展了这个技巧，来判断两个其它地址，也就是返回地址retaddr和返回地址位置retloc，并使用它来构建完整的偏移独立的 wu-ftpd 利用程序（7350wu [22]）。
为了爆破这个距离，你应该像这样使用格式化字符串。
"AAAABBBB|stackpop|%08x|"stackpop取决于我们打算猜测的距离。距离在每次尝试中都会增加：
while (distance > 0) {
strcat (stackpop, "%u");
distance -= 4;
}如果我们探测距离 32，格式化字符串为：
"AAAABBBB|%u%u%u%u%u%u%u%u|%08x|"我们从栈上弹出了 32 个字节（8 个%u），并以十六进制，打印了第 32 字节位置的四个字节。理想情况下的输出为：
AAAABBBB|983217938177639561760134608728913021|41414141|41414141是AAAA是十六进制形式，我们越过了整好 32 字节的距离。如果你不能通过增加距离到达该模式串，这有两个原因：一是距离太大无法到达，例如如果格式化字符串位于堆上，二是不是以四字节对齐。在后者的情况中，我们仅仅需要在格式化字符串前面插入一个到三个伪造字节。之后我们可以滑动字符串的位置，以便模式串42414141变为正确的模式串41414141。
一旦你设置了对齐和距离，你就可以爆破格式化字符串的缓冲区地址了。因此你使用这样的格式化字符串：
addr|stackpop|______________________________%%|%s|格式化字符串从左到右处理，addr和___序列没有任何害处。stackpop将栈指针向上移动，直到它指向addr地址。最后%s打印出addr处的 ASCIIZ 字符串。
在理想情况下，addr会指向我们格式化字符串的___序列。这里输出为：
garbage|___________________________%|______%%|%s||其中garbage由addr和stackpop输出组成。之后处理的___%%字符串会转换为___%，因为%%被格式化字符处理器转换为%。之后字符串______%%|%s|被插入，因为我们提供的格式化字符串的%s被处理。要注意在我们尝试处理不同的addr值，它是唯一会发生变化的值。在我们的理想情况下，我们让addr直接指向我们的缓冲区。你可以看到，通过观察%%，我们可以分辨出指向我们的格式化字符串的地址（带有两个%字符），以及偶然指向目标缓冲区（只有一个%字符，由于被格式化函数转义）的指针。
如果addr指向了目标缓冲区，输出为：
garbage|___________________________%|______%||你可以看到，只有一个%字符。这让我们能够精确预测目标缓冲区，对于格式化字符串在堆中的情况，这会非常有用。
由于我们知道了，我们的%s相对于格式化字符串的起始位于哪里，并且我们拥有了指向缓冲区的地址，我们就可以将地址重定向，以便精确了解我们的格式化字符串在哪里开始。由于你通常希望将 shellcode 放在格式化字符串中，你可以准确计算出相对于格式化字符串地址的retaddr。
5.2 盲爆破
盲爆破不像基于响应的爆破那样直接。基本的理念是，我们可以测量出远程计算机处理格式化字符串的所需时间。类似%.9999999u比简单的%u花费的时间要长。同样，通过在未映射的地址上使用%m，我们可以可靠地产生段错误。
此类爆破的这一基本的方式由 tf8 发明，之后由我改进来爆破缓冲区地址。
由于这个工具相对复杂，并且仅仅可用于特殊的场景，我在example/目录下提供了可用的示例。如果你可以多次触发案例，但是不能查看格式化函数的响应，例如在syslogs服务中，这是个有意思的东西。
如果你对这个技巧感兴趣，请参见源码，我在此处就不描述了。