Du4t's Blog
[Fuzz] ADVANCED FUZZING UNMASKS ELUSIVE VULNERABILITIES
编辑
2023-12-01
Fuzz
00
请注意，本文编写于 490 天前，最后修改于 490 天前，其中某些信息可能已经过时。

目录

ADVANCED FUZZING UNMASKS ELUSIVE VULNERABILITIES
Introduction
Step 1: Fuzzing Prep
Step 2: Focusing on the Vulnerable Code Path
Step 3: Preparing the code for fuzzing
Step 4: Launching the fuzzing campaign
Step 5: Profit?
Lesson Learned
Evaluating OSS-Fuzz's Discovery Gap

😀

ADVANCED FUZZING UNMASKS ELUSIVE VULNERABILITIES

Introduction

模糊测试是现代软件保障的主要组成部分，但有些漏洞仍然难以模糊测试。

谷歌的 libwebp 是 Chrome 浏览器和 Safari 浏览器不可或缺的部分，最近因一个严重的安全漏洞而受到关注，该漏洞已被发现在野外被利用。值得注意的是，包括 OSS-Fuzz 在内的谷歌庞大的模糊测试系统并未发现该漏洞。

正如来自 Isosceles 的 Ben Hawkes 所详述的，该漏洞存在于 WebP 的无损压缩方法 VP8L 中。基于预先计算的固定缓冲区大小的内存分配导致了堆缓冲区溢出。

如果有足够的时间和可解路径限制，Fuzzers 通常能够发现这种复杂的内存损坏。然而，这个特定的错误却逃过了之前的模糊测试尝试。

模糊社区和我们都在问这样一个问题：是否有可能通过模糊找到这个特定的漏洞？如果可能，为什么 Google 的 OSS-Fuzz 计划没有发现它？本文试图回答这些问题，并为更好地开展模糊测试活动提供指导。

注：在本文的第一次迭代中，模糊设置发现了 libwebp 漏洞，但这是由于在活动中意外添加了一个已经部分损坏的输入文件作为种子而造成的错误。

Step 1: Fuzzing Prep

作为 AFL++ 的主要开发人员，我想了解为什么某些 bug 能够逃过自动化工具的检测，以及我们如何改进工具以提高 bug 的覆盖率。

如果您是模糊测试的新手，不妨先了解一下 AFL++：

https://github.com/AFLplusplus/AFLplusplus/blob/stable/docs/fuzzing_in_depth.md

https://github.com/AFLplusplus/AFLplusplus/blob/stable/docs/afl-fuzz_approach.md

https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.cmplog.md

https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.laf-intel.md

如果没有安装完整的现代 LLVM 编译器和其他必要的构建工具，安装 AFL++ 也很简单（见 https://github.com/AFLplusplus/AFLplusplus/blob/stable/docs/INSTALL.md）

为了测试，我们使用了漏洞修复前的 libwebp 版本：

bash
$ git clone https://chromium.googlesource.com/webm/libwebp
$ cd libwebp
$ git checkout 7ba44f80f3b94fc0138db159afea770ef06532a0

我们选择不依赖已有的harness或构建一个新的harness，而是使用库中自带的示例工具，因为我们知道这可以用来触发 bug。假设这些harness的模糊测试范围很窄，这可能是没有发现漏洞的原因。为了优化速度，我们将 forkserver 移到了 dwebp 代码中，就在解析输入之前。最后，我们将 makefile.unix 中的编译器调整为 AFL++。

diff
diff --git a/examples/dwebp.c b/examples/dwebp.c
index 652de6a6..d41df43d 100644
--- a/examples/dwebp.c
+++ b/examples/dwebp.c
@@ -312,6 +312,10 @@ int main(int argc, const char* argv[]) {
if (quiet) verbose = 0;
+#ifdef __AFL_HAVE_MANUAL_CONTROL
+  __AFL_INIT();
+#endif
+
  {
    VP8StatusCode status= VP8_STATUS_OK;
    size_t data_size = 0;
diff --git a/makefile.unix b/makefile.unix
index 857ea988..83d04a9c 100644
--- a/makefile.unix
+++ b/makefile.unix
@@ -113,7 +113,7 @@ else
  CFLAGS = -O3 -DNDEBUG
endif
CFLAGS += $(EXTRA_FLAGS)
-CC = gcc
+CC = afl-clang-fast
INSTALL = install
GROFF =/usr/bin/groff
COL = /usr/bin/col

Step 2: Focusing on the Vulnerable Code Path

我们希望 AFL++ 只关注导致这一特定 bug 的代码路径。为此，我们使用了源代码覆盖编译标志（-fprofile-arcs -ftest-coverage -lgcov--coverage）。然后，我们使用有问题的 bad.webp 文件运行目标 examples/dwebp bad.webp -o /dev/null。

由于崩溃不会生成覆盖文件，因此我们事先还修改了源代码，以强制写入覆盖文件：

diff
diff --git a/src/dec/vp8l_dec.c b/src/dec/vp8l_dec.c
index 45012162..836540fa 100644
--- a/src/dec/vp8l_dec.c
+++ b/src/dec/vp8l_dec.c
@@ -360,6 +360,8 @@ static int ReadHuffmanCode(intalphabet_size, VP8LDecoder* const dec,
  return size;
}
+void __gcov_dump(void);
+
static intReadHuffmanCodes(VP8LDecoder* const dec, int xsize, int ysize,
                           int color_cache_bits, int allow_recursion) {
  int i, j;
@@ -378,6 +380,8 @@ static int ReadHuffmanCodes
(VP8LDecoder*const dec, int xsize, int ysize,
  int* mapping = NULL;
  int ok = 0;
+  __gcov_dump();
+
  if (allow_recursion&& VP8LReadBits(br, 1)) {
    // use meta Huffmancodes.
    const int huffman_precision = VP8LReadBits(br, 3) + 2

强制写入覆盖文件后，我们使用实用程序 gcov 来解析和分析生成的覆盖文件。我们确定了涉及崩溃的函数名称，以便只对这些特定函数进行测试，从而更有效地引导模糊器找到漏洞。这样做可以大大加快目标模糊过程。虽然模糊器最终也能找到漏洞，但在这个特定实验中，引导它将节省大量时间。

我们创建了一个名为 libwebp.list 的文件，其中包含与崩溃路径相关的待检测函数名称：

fun: CheckSizeArgumentsOverflow
fun: CheckSizeOverflow
fun: DefaultFeatures
fun: GetCPUInfo
fun: GetLE16
fun: GetLE32
fun: main
fun: PrintAnimationWarning
fun: ShiftBytes
fun: VP8InitIo
fun: VP8InitIoInternal
fun: VP8LCheckSignature
fun: VP8LDecodeHeader
fun: VP8LIsEndOfStream
fun: VP8LPrefetchBits
fun: VP8LReadBits
fun: WebPInitCustomIo
fun: WebPInitDecBuffer
fun: WebPInitDecBufferInternal
fun: WebPInitDecoderConfig
fun: WebPMalloc
fun: WebPResetDecParams
fun: WebPSafeCalloc
fun: WebPSafeMalloc
fun: x86CPUInfo

Step 3: Preparing the code for fuzzing

为了实现彻底的模糊测试，我们需要对覆盖率有不同看法的模糊测试实例--为此，我们使用上下文敏感覆盖率（CTX）和步长为 8 的基于 N 序列的仪器（NGRAM-8）编译了额外的实例。此外，我们还需要有助于解决路径限制的模糊实例，为此我们编译了 CMPLOG 和 COMPCOV 附加实例。

最后，我们添加了一个实例，通过启用 ASAN，可以轻松检测任何类型的内存损坏。

bash
$ export AFL_LLVM_ALLOWLIST=/full/path/to/libwebp.list
$ for i in cmplog compcov ctx ngram asan; do
	  cp -r libwebp libwebp-$i
 done
$ make -C libwebp -f makefile.unix
$ make AFL_USE_ASAN=1 -C libwebp-asan -f makefile.unix
$ make AFL_LLVM_CMPLOG=1 -C libwebp-cmplog -f makefile.unix
$ make AFL_LLVM_LAF_ALL=1 -C libwebp-compcov -f makefile.unix
$ make AFL_LLVM_INSTRUMENT=CTX -C libwebp-ctx -f makefile.unix
$ make AFL_LLVM_INSTRUMENT=NGRAM-8 -C libwebp-ngram -f makefile.unix

请注意，在实际的模糊测试活动中，您可能会添加一个 honggfuzz 实例和一个带有 "value-profile "的 libfuzzer 实例，可能还会添加一个 libafl 和一个协程执行模糊器，如 symcc 和 .TritonDSE。为了不使本文过于复杂，此处省略了这些内容。

Step 4: Launching the fuzzing campaign

起初，我们从 libwebp 中收集了一些种子文件，并随机下载了一些文件，将它们放在名为 "seeds"的目录中。为确保模糊器拥有多样化的输入，我们运行了重复数据删除命令：

bash
$ afl-cmin -i seeds -o inputs
[... output omitted ...]
$ ls -l inputs/
-rw-r--r-- 2 marc 1013  50408 Okt  6 14:15 file_example_WEBP_50kB.webp
-rw-r--r-- 2 marc 1013  71272 Okt  6 14:15 Huey_helicopter_USNS.webp
-rw-rw-r-- 9 marc 1013   4880 Okt  6 14:15 test.webp
-rw-rw-r-- 9 marc 1013 1321542 Okt  6 14:15 test_webp_wasm.webp
-rw-r--r-- 2 marc 1013  81150 Okt  6 14:15 foobar.webp

有了五个独特的种子文件，我们就可以开始模糊测试了。我们设置了 8 个不同的 "screen"会话，每个会话都有不同的配置，目的是实现多样化的模糊设置。\

sh
#!/bin/bash
export AFL_FAST_CAL=1 AFL_IMPORT_FIRST=1 AFL_DISABLE_TRIM=1 AFL_AUTORESUME=1
$*

bash
# A simple MAIN instnace
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-main -M main -- libwebp/examples/dwebp @@ -o /dev/null
# Our ASAN instance to help finding non-crashing memory corruptions
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-asan -S asan -- libwebp-asan/examples/dwebp @@ -o /dev/null
# Our path constraint solving instances
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-cmplog2 -S cmplog2 -l2at -c libwebp-cmplog/examples/dwebp -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-cmplog3 -S cmplog3 -l3a -c libwebp-cmplog/examples/dwebp -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-compcov -S compcov -- libwebp-compcov/examples/dwebp @@ -o /dev/null
# Alternative coverage gathering
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-ngram -S ngram -- libwebp-ngram/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-ctx -S ctx -- libwebp-ctx/examples/dwebp @@ -o /dev/null
# Various instances that fuzz a bit differently to add to the diversity
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-default -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-binexploit -S binexploit -a binary -P exploit -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-binexplore -S binexplore -a binary -P explore -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-ascexploit -S ascexploit -a ascii -P exploit -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-ascexplore -S ascexplore -a ascii -P explore -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-genericexploit -S genericexploit -P exploit -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-genericexplore -S genericexplore -P explore -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-rare -S rare -p rare -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-Z -S Z -Z -- libwebp/examples/dwebp @@ -o /dev/null

显然，对 AFL++ 功能的深刻理解和经验是必不可少的。不过，对于那些热衷于深入研究的人来说，https://github.com/AFLplusplus/AFLplusplus/blob/stable/docs/fuzzing_in_depth.md 上的文档提供了详尽的见解。

Small Tips

  1. libwebp.list有什么作用

    设置 export AFL_LLVM_ALLOWLIST=libwebp.list 将仅插桩内部包含的函数

  2. -l2at

    -l cmplog_opts - CmpLog configuration values (e.g. "2ATR"): 1=small files, 2=larger files (default), 3=all files, A=arithmetic solving, T=transformational solving, X=extreme transform solving, R=random colorization bytes.

  3. -P

    -P strategy - set fix mutation strategy: explore (focus on new coverage), exploit (focus on triggering crashes). You can also set a number of seconds after without any finds it switches to exploit mode, and back on new coverage (default: 1000)

  4. -a

    -a - target input format, "text" or "binary" (default: generic)

  5. -p

    -p schedule - power schedules compute a seed's performance score: fast(default), explore, exploit, seek, rare, mmopt, coe, lin quad -- see docs/FAQ.md for more information

  6. -Z

    -Z - sequential queue selection instead of weighted random

  7. AFL_FAST_CAL

    AFL_FAST_CAL: limit the calibration stage to three cycles for speedup

  8. AFL_IMPORT_FIRST

    AFL_IMPORT_FIRST: sync and import test cases from other fuzzer instances first

  9. AFL_DISABLE_TRIM

    AFL_DISABLE_TRIM: disable the trimming of test cases

  10. AFL_AUTORESUME

    AFL_AUTORESUME: resume fuzzing if directory specified by -o already exists

Step 5: Profit?

3 天后，我们检查了结果，没有发现崩溃。只有当添加的输入已有 2/3 的所需特殊设置表时，漏洞才会被发现，但此时仍需要约 40 小时才能触发。

分析该漏洞所需的确切表格设置就能发现原因所在：

c
   // Size of huffman_tables buffer = 654 + 630 + 630 + 630 + 410 = 2954 elements
   // To overflow we "just" exceed this number!
   static uint32_t code_lengths_counts[5][16] = {
       //  1  2  3  4  5  6  7  8  9  10   11  12 13 14 15
       {0, 1, 1, 0, 0, 0, 0, 0, 0, 3, 229, 41,  1, 1, 1, 2},   // size = 654
       {0, 1, 1, 0, 0, 0, 0, 0, 0, 7, 241,  1,  1, 1, 1, 2},   // size = 630
       {0, 1, 1, 0, 0, 0, 0, 0, 0, 7, 241,  1,  1, 1, 1, 2},   // size = 630
       {0, 1, 1, 0, 0, 0, 0, 0, 0, 7, 241,  1,  1, 1, 1, 2},   // size = 630
       {0, 1, 1, 1, 1, 1, 0, 0, 0, 11, 5,   1, 10, 4, 2, 2},   // size = 414
   };

模糊器需要找到一个非常特殊的字节组合，才能创建一个大小正确的表来触发这个错误。低于这个数字就不会崩溃，高于这个数字就会检测到无效表并中止处理。

如果存在导致崩溃的特定程序流程，模糊器就能很好地发现这一点。如果需要一个常见的特定值（如 0xffffffffffff），那么模糊器也能很好地找到这个值。

但是，要找到一长串特定值（其中许多值都不是 0、1 或 255）则是一项挑战，因为必须在没有路径约束求解或覆盖率帮助的情况下找到更多这些值，或者在运行时从目标中动态学习值是不可能的。

在这种特定情况下，模糊器需要在没有任何帮助的情况下猜测大约 20 个字节的特定值，这需要数千年的时间（比喻，需要更长的时间）才能随机找到这样的设置。其他机制，如协程求解器，也无法发现此类问题。可能只有证明内存安全性的正式验证方法才有可能发现这一漏洞，但这并不是可以轻易设置和应用的。

Lesson Learned

只检测漏洞的执行路径，看看模糊测试是否能找到它，或者它为什么会失败，这种技术对于在短时间内获得这些信息非常有价值。如果没有在步骤 2 中进行的优化，要得出同样的结论可能需要大约 1 个核心年的时间。

这个 libwebp 漏洞提醒我们，模糊测试并非灵丹妙药。有些漏洞无法通过模糊测试发现，有些漏洞则需要模糊测试仪无法生成的触发器或大量数据。

这并不是模糊测试第一次没有发现令人瞩目的漏洞，也不可能发现。

有时是因为线束限制，比如臭名昭著的 heartbeet 漏洞。有时是因为模糊器没有覆盖漏洞类型，比如臭名昭著的 Shellshock 漏洞有时是因为无法触发漏洞条件，如 libwebp 漏洞或 OpenSSL 中使用 punycode 进行证书解析时出现的内存损坏。

手动代码检查、静态分析工具、自动测试和动手安全测试相结合，才能全面识别软件中的漏洞。仅仅依靠模糊测试会让自己陷入失败的境地。

Evaluating OSS-Fuzz's Discovery Gap

尽管在 libwebp 项目的 tests/fuzzer/subdirectory 中存在harness，但 OSS-Fuzz 并未发现该漏洞。我们发现，七个线束中有两个（simple_api_fuzzer 和 advanced_api_fuzzer）确实能触发 bad.webp 崩溃：

bash
$ libwebp/tests/fuzzer/simple_api_fuzzer bad.webp
Reading 236 bytes from bad.webp
=================================================================
==13217==ERROR: AddressSanitizer:heap-buffer-overflow on address
0x626000002f28 at pc 0x555555701767 bp0x7fffffffd1f0 sp 0x7fffffffd1e8
[…]
SUMMARY: AddressSanitizer: heap-buffer-overflow/data/marc-
webp/libwebp/src/utils/huffman_utils.c:59:18 in ReplicateValue

它根本没有机会找到触发错误所需的特定设置，所以这不是 OSS-Fuzz 的错。

不过，我们发现 OSS-Fuzz 执行模糊测试的方式存在一些问题，导致模糊测试无法充分发挥潜力：

  1. 静态插桩： 最初，我为 AFL++ 集成到 OSS-Fuzz 中实施了一项功能，每次编译代码时都会以不同的方式随机检测代码。这增加了发现新覆盖率和后续错误的概率。然而，由于复杂的原因，谷歌团队取消了这一功能，将模糊测试限制为一组标准的仪器选项。这就限制了 OSS-Fuzz 对覆盖率和路径限制的查看。

  2. 语料库同步问题： OSS-Fuzz 使用 ClusterFuzz 来处理实际的模糊工作量。一个实例独立工作，然后将其结果合并到主语料库中。用于合并的方法是 "libfuzzer"，它看到的覆盖率远低于 AFL++，尤其是 AFL++ 的 COMPCOV 等功能，因此每次都会损失 AFL++ 发现的覆盖率的 10-20%。

  3. 最后，OSS-Fuzz 以 CI 方式运行 ClusterFuzz，单个实例只运行几个小时，然后终止。对于大型语料库或速度较慢的目标，首先进行校准的智能模糊器的启动时间非常长，留给实际模糊处理的时间很少。

有些错误无法通过基于 CI 的模糊测试有效发现，而是需要长时间的模糊测试，使用不同的技术来解决路径限制问题： CMPLOG、COMPCOV、libfuzzer 的值轮廓，以及中小型项目中的一个或两个协程执行框架，为什么还要使用不同的覆盖选项（如 CTX 和/或 NGRAM），以及并行运行多个不同的实例呢？

本文作者:Du4t

本文链接:

版权声明:本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！