概观
在第2部分中,我们为ASX To MP3 Converter构建了一个基本的栈溢出攻击。正如我在那篇文章中指出的那样,利用本身并不完美。成功的EIP覆盖受m3u文件的文件路径的影响。另外,虽然在选择跳转/调用地址时首选应用程序模块,但我们使用的应用程序DLL是重新分配的,这意味着我们的CALL EBX指令的地址可能会更改,因此不可靠。在这一部分中,我们将仔细研究这些问题以及一些可以改进我们的原始漏洞使其更可靠的方法。
更改EIP偏移量
我在第2部分强调的一件事情是,如果m3u文件是从C:目录的根目录运行的,ASX To MP3 Converter的漏洞利用工作才起作用,因为EIP覆盖的偏移取决于文件路径。如果要验证,请尝试将m3u文件从C:移动到桌面,然后重试调试器中的漏洞。请参阅下面的屏幕截图。
正如您所看到的,EIP现在不会被我们的CALL EBX指令覆盖,而是被我们payload的前面“垃圾”部分覆盖,这部分由A( x41)组成。由于较长的文件路径被合并到有效载荷中,因此它将所有内容都推向右侧,并将EIP更改为'AAAA'。
如果您记得,我们完整的exploit缓冲区看起来像这样:
EIP的偏移量(当m3u文件位于C:的根目录时)为26,121字节。正如我们通过将m3u文件移动到桌面所证明的那样,较长的文件路径会导致EIP覆盖为A。如果文件路径是对偏移量的唯一影响,我们应该能够准确预测新偏移量。让我们为m3u文件选择一个不同的保存位置来证明这一理论。位于我的桌面上的m3u文件的完整路径如下(其中Documents and Settings Administrator Desktop 是较c:多出来的路径长度):
C:Documents and Settings Administrator Desktop asx2mp3.m3u
这条新路径长45个字符,这意味着我们应该调整我们的EIP偏移-45,新的偏移量26076。让我们更新我们的漏洞利用代码,看看它是否有效(只改变你在第2部分中建立的利用漏洞的偏移量)。
基于应用程序的模块
在重新启动的Windows计算机上运行具有更新偏移量的漏洞利用程序会产生以下结果:
EIP显然已被我选择的CALL EBX地址(来自MSA2Mcodec00.dll的0x01C27228)覆盖,但该程序似乎并未将其识别为有效地址。这里出现的问题,因为在我的漏洞利用代码中,我使用了来自重定位应用程序模块(DLL)的地址。
在没有详细介绍重新绑定的情况下,要明白每个模块都有一个指定的基地址,它应该加载在这个地址上(而且编译器通常有一个默认的地址分配给所有的模块)。
如果在加载时发生地址冲突