转载

Fuzzing初学者指南：利用Address Sanitizer找到更多BUG

内存访问错误是模糊测试通常能够发现的一类错误，其主要是由于程序对不该进行读写操作的内存进行了操作，从而导致了应用程序的崩溃。

实际上并不是所有的内存访问错误都能发生崩溃。

下面是段简单的C代码，我们把它另存为test.c来作为一个例子：

int main() {     int a[2] = {1, 0};     int b=a[2]; }

我们可以看出这是一个经典的 off-by-one-error错误：定义一个有两个元素的数组，访问该数组的元素时需从0开始，因此该数组的两个元素分别为a[0]、a[1]。然后将a[2]赋值给b,但实际上a[2]不是数组的一部分，是个无效的数值。所以b最终就成了一个任意的数值，它只是从堆栈和内存中未被定义的部分中读取了“一些”内存。

然而和其他的内存访问错误所不同的是，它并不会造成崩溃，即使是强大的 valgrind 也无法告诉我们具体问题在哪里。而在最新版本的 llvm和gcc中有一款工具却可以发现这种错误，它就是Address Sanitizer (ASan) ，它可以直接在编译的时候进行使用。

不过要注意的是，在使用前我们需要在编译器标志中增加一个参数-fsanitize=address。另外，为了使调试更为轻松，我们还需要增加 -ggdb.

gcc -fsanitize=address -ggdb -o test test.c

现在，我们再去运行之前的那个例子，我们会得到一个彩色的错误信息：

==7402==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff2971ab88 at pc 0x400904 bp 0x7fff2971ab40 sp 0x7fff2971ab30READ of size 4 at 0x7fff2971ab88 thread T0  #0 0x400903 in main /tmp/test.c:3  #1 0x7fd7e2601f9f in __libc_start_main (/lib64/libc.so.6+0x1ff9f)  #2 0x400778 (/tmp/a.out+0x400778) Address 0x7fff2971ab88 is located in stack of thread T0 at offset 40 in frame  #0 0x400855 in main /tmp/test.c:1   This frame has 1 object(s):  [32, 40) 'a' <== Memory access at offset 40 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext    (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow /tmp/test.c:3 main

我选择了其中最为有趣的一部分，相信这部分已经完全足够说明发生了什么——测试代码的第三行中由于一个大小为4的无效读取导致出现了栈溢出（一个整数的大小）。

这里需要注意的是，旧版本的 Address Sanitizer（gcc4.9以前）可能会产生比较少的可读输出，如果你不想用一个新的编译器，可以选择用一个python脚本去解析ASan的输出。

使用Address Sanitizer进行软件开发

我们在进行模糊测试时，通常对象不会是一个简单的C文件，因此我们必须要把address sanitizer添加到编译器的标志寄存器中。而软件所使用的正常配置脚本则如下所示：

./configure --disable-shared CFLAGS="-fsanitize=address -ggdb" CXXFLAGS="-fsanitize=address -ggdb" make

为了获得更多的调试信息，我们需要再一次的添加-ggdb。如果可能的话我们还可以禁用共享库并设置C和C++编译器的标志。

然后，我们就可以像第一部分所说的那样对运行中的软件进行畸形输入了。而当我们将输出重定向到日志文件时，我们就不得不考虑到我们不能够对分段错误进行grep，而是需要我们去grep Address Sanitizer的消息：

grep AddressSanitizer fuzzing.log

在使用Address Sanitizer时，我们还必须要考虑到一些事：

1、ASan发现内存访问违规的时，应用程序并不会自动崩溃。这是由于在使用模糊测试工具时，它们通常都是通过检查返回码来检测这种错误。当然，我们也可以在模糊测试进行之前通过将环境变量 ASAN_OPTIONS修改成如下形式来迫使软件崩溃：

export ASAN_OPTIONS='abort_on_error=1'/

2、 ASan需要相当大的虚拟内存（大约20TB），不用担心，这个只是虚拟内存，你仍可以使用你的应用程序。但像 american fuzzy lop这样的模糊测试工具就会对模糊化的软件使用内存进行限制，不过你仍可以通过禁用内存限制来解决该问题。唯一需要注意的就是，这会带来一些风险：测试样本可能会导致应用程序分配大量的内存进而导致系统不稳定或者其他应用程序崩溃。因此在进行一些重要的模糊测试时，不要去尝试在同一个系统上禁用内存限制。

3、 Zzuf目前并不能和 ASan协同工作，但你仍可以使用zzuf手动去创建一些测试样本将他们输入ASan的编译软件中。

4、还有就是，ASan会显著的延缓执行，其所发现的bug往往没有那么严重（当然也有例外），不过它能发现更多的bug是毋庸置疑的。

* 参考来源 fuzzing-project ，编译：ch4nge，转载请注明来自FreeBuf黑客与极客（FreeBuf.COM）

正文到此结束