glibc fnmatch漏洞:如何暴露漏洞？

Question

我必须在运行glibc-2.9的64位系统上验证一个漏洞。

http://scarybeastsecurity.blogspot.in/2011/02/i-got-accidental-code-execution-via.html

上面的链接给出了一个脚本，当传递一个魔术数字时，显然会导致任意代码的执行。但当我在我的系统上尝试它时，似乎什么都没有发生。我做错了什么吗？如果存在漏洞，系统会崩溃吗？我如何检测它是否是意外的代码执行？

Answer 1

如果您在64位计算机上遇到此问题，则必须模仿原始代码，但在64位计算机上提供一个包装堆栈的数字。提供的原始数字为：

1073741796

$ bc
z=1073741796
z+28
1073741824
(z+28)*4
4294967296
2^32
4294967296
quit
$

因此，描述输入数字的一种方法是(ULONG_MAX - 112) / 4。

64位机器的模拟数字是4611686018427387876：

$ bc
x=2^64
x
18446744073709551616
y=x/4
y
4611686018427387904
y-28
4611686018427387876
quit
$

然而，为了有机会实现这一点，您必须修改报告的代码以使用strtroull()或类似的代码；atoi()通常被限制为32位整数，并且对上面的64位数字没有用处。代码还包含：

num_as = atoi(argv[1]);
if (num_as < 5) {
    errx(1, "Need 5.");
}
p = malloc(num_as);

其中num_as是size_t，p是char *。因此，您必须能够malloc()大量的空间(几乎4 EiB)。大多数人在他们的机器上没有足够的虚拟内存，即使有磁盘空间来支持，也不能做到这一点。现在，也许，仅仅是也许，Linux会允许你过度提交(并让OOM Killer稍后进入)，但是malloc()更有可能失败。

还有一些其他相关的特性会影响32位系统，但不会影响64位系统(目前还没有)。

如果您打算在64位计算机上重现它，那么您可能必须进行32位编译。然后，如果风向已经过去，并且您有适当的旧版本的相关软件，也许您可以重现它。

Answer 2

如果你在64位机器上运行，那么bug的原始环境就不适用了。正如你在Chris的博客中看到的，他使用的是32位的Ubuntu 9.04系统。该攻击依赖于使堆栈指针环绕32位地址空间，从而导致堆栈损坏。

我在安装了glibc 2.5的64位系统上快速尝试了一下，但看到的是malloc()失败，而不是崩溃。

$ ./a.out 3000000000
a.out: malloc() failed.

您问过如何识别意外的代码执行；对于这里的玩具程序，它没有携带利用漏洞/有效负载，当CPU试图“执行”堆栈的垃圾部分时，我们预计会看到SIGSEGV、SIGILL或SIGBUS，并显示为来自shell的相应错误消息。