Question

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

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

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

Answer 1

如果您在64位计算机上运行，则该错误的原始情况不适用。正如你在Chris的博客中看到的那样，他使用的是32位Ubuntu 9.04系统。漏洞依赖于导致堆栈指针绕过32位地址空间，导致堆栈损坏。

我快速尝试使用glibc 2.5的64位系统，但看到malloc（）失败而不是崩溃。

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

您询问了如何识别意外的代码执行;使用这里没有漏洞/有效载荷的玩具程序，我们期望看到SIGSEGV，SIGILL或SIGBUS，因为CPU试图“执行”堆栈的垃圾部分，显示为相应的错误来自shell的消息。

Answer 2

如果您在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杀手稍后猛扑），但malloc()更有可能失败。

还有其他相关的功能会影响32位系统，但它不会影响64位系统。

如果你有机会在64位机器上重现它，你可能需要进行32位编译。然后，如果风在你身后，你有相应软件的相应旧版本，也许你可以重现它。

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

2 个答案: