定向灰盒模糊测试（DGF）如 AFLGo 旨在对预先选定的潜在易受攻击目标位置进行压力测试，适用于不同的安全场景：（1）漏洞复现，（2）补丁测试或（3）静态分析报告验证。近期有更多研究工作提升了定向模糊测试的有效性和效率（参见 awesome-directed-fuzzing）。
我们提出 UAFuzz，这是一个专注于二进制级释放后使用（UAF）漏洞的定向模糊器，通过精心调整定向模糊测试的关键组件，以适应此类漏洞的具体特征。UAF 漏洞在堆元素被释放后被使用时出现。检测 UAF 漏洞很困难：（1）复杂性，因为概念验证（PoC）输入需要触发同一内存位置上的三个事件序列——分配、释放和使用，这些事件跨越被测程序的多个函数；（2）无提示，不会发生段错误。
总体而言，UAFuzz 的工作流程与定向模糊器相似，我们的修改在整个模糊测试过程中以橙色突出显示，如下图所示。由于我们专注于（1）漏洞复现和（2）补丁测试应用，我们更有可能拥有所有内存相关 UAF 事件的*（大部分）完整堆栈跟踪*。与现有的通用定向方法（其中目标可以独立选择）不同，我们考虑了目标之间的关系（例如，对 UAF 至关重要的顺序）以提高定向性。首先，UAFuzz 的静态预计算在二进制级是快速的。其次，我们引入了新的顺序感知输入度量，以在运行时引导模糊器走向目标。最后，我们仅对覆盖预期跟踪中所有目标的潜在输入进行分流，并预过滤不太可能触发漏洞的输入。
更多详情请见我们在 RAID'20 上的论文和在 Black Hat USA'20 上的演讲。同时感谢 Sébastien Bardin、Matthieu Lemerre、Prof. Roland Groz，尤其感谢 Richard Bonichon（@rbonichon）在 Ocaml 方面的帮助。
我们的测试环境是 Ubuntu 16.04 64 位。
# 通过 OPAM 安装 Ocaml 和 BINSEC 所需的依赖包
sudo apt update
sudo apt update
sudo apt install ocaml ocaml-native-compilers camlp4-extra opam emacs llvm-6.0-dev pkg-config protobuf-compiler libgmp-dev libzmq3-dev cmake valgrind
opam init
opam switch 4.05.0
opam depext conf-m4.1
opam install merlin ocp-indent caml-mode tuareg menhir ocamlgraph ocamlfind piqi zmq.5.0.0 zarith llvm.6.0.0
eval `opam config env`
# 安装 Python 包（用于 IDA 脚本的 Python 2）
sudo python -m pip install networkx pydot
sudo apt install graphviz
# 安装 Graph Easy
wget https://cpan.metacpan.org/authors/id/S/SH/SHLOMIF/Graph-Easy-0.76.tar.gz
tar xzf Graph-Easy-0.76.tar.gz
cd Graph-Easy-0.76
perl Makefile.PL; make test; sudo make install
export GRAPH_EASY_PATH=/usr/local/bin/graph-easy
# 检出源代码
git clone https://github.com/strongcourage/uafuzz.git
# 环境变量
export IDA_PATH = /path/to/ida-6.9/idaq
export GRAPH_EASY_PATH=/path/to/graph-easy
cd uafuzz; export UAFUZZ_PATH=`pwd`
# 编译源代码
./scripts/build.sh uafuzz
# IDA/UAFuzz 接口帮助
./binsec/src/binsec -ida-help
./binsec/src/binsec -uafuzz-help
我们的模糊器基于 AFL v2.52b 的 QEMU 模式进行模糊测试，并利用 BINSEC 进行轻量级静态分析（参见 uafuzz/README.md）。我们目前使用 IDA Pro v6.9 提取被测二进制的控制流图（CFG）和调用图（参见 ida/README.md）。
uafuzz
├── binsec/src
│ └── ida: 用于导入和处理 IDA 的 CFG 和调用图的插件
│ └── uafuzz: 模糊测试代码
│ │ └── afl-2.52b: 基于 AFL-QEMU 构建的核心模糊测试
│ │ └── uafuzz_*.ml(i): 用于计算静态信息并与 AFL-QEMU 通信的插件
└── scripts: 一些构建和漏洞分流的脚本
我们首先考虑一个简单的 UAF 漏洞。AFL-QEMU 甚至定向模糊器 AFLGo（目标位于源代码级）都无法在 6 小时内检测到此漏洞，而 UAFuzz 借助 Valgrind 的 UAF 报告在几分钟内即可检测到。
# 运行 AFL-QEMU
$UAFUZZ_PATH/tests/example.sh aflqemu 360
# 运行 AFLGo（目标位于源代码级）
$UAFUZZ_PATH/tests/example.sh aflgo 360
# 运行 UAFuzz
$UAFUZZ_PATH/tests/example.sh uafuzz 360 $UAFUZZ_PATH/tests/example/example.valgrind
对于真实世界的程序，我们使用 UAF 模糊测试基准进行评估。
# 检出基准
git clone https://github.com/strongcourage/uafbench.git
cd uafbench; export UAFBENCH_PATH=`pwd`
我们将详细展示如何使用 UAFuzz 进行 readelf（Binutils）的 CVE-2018-20623 漏洞复现。Valgrind 获取的此 UAF 漏洞堆栈跟踪如下：
// 错误使用的堆栈跟踪
==5358== Invalid read of size 1
==5358== at 0x40A9393: vfprintf (vfprintf.c:1632)
==5358== by 0x40A9680: buffered_vfprintf (vfprintf.c:2320)
==5358== by 0x40A72E0: vfprintf (vfprintf.c:1293)
[6] ==5358== by 0x80AB881: error (elfcomm.c:43)
[5] ==5358== by 0x8086217: process_archive (readelf.c:19409)
[1] ==5358== by 0x80868EA: process_file (readelf.c:19588)
[0] ==5358== by 0x8086B01: main (readelf.c:19664)
// 释放的堆栈跟踪
==5358== Address 0x4221dc0 is 0 bytes inside a block of size 80 free'd
==5358== at 0x402D358: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
[4] ==5358== by 0x8086647: process_archive (readelf.c:19524)
[1] ==5358== by 0x80868EA: process_file (readelf.c:19588)
[0] ==5358== by 0x8086B01: main (readelf.c:19664)
// 分配的堆栈跟踪
==5358== Block was alloc'd at
==5358== at 0x402C17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
[3] ==5358== by 0x80AD97E: make_qualified_name (elfcomm.c:906)
[2] ==5358== by 0x8086350: process_archive (readelf.c:19435)
[1] ==5358== by 0x80868EA: process_file (readelf.c:19588)
[0] ==5358== by 0x8086B01: main (readelf.c:19664)
预处理脚本以 x86 格式的被测二进制文件和 Valgrind 的堆栈跟踪作为输入，然后生成 UAF 漏洞跟踪，该跟踪是以下格式的目标位置序列 (basic_block_address,function_name)：
[0] (0x8086ae1,main) -> [1] (0x80868de,process_file) -> [2] (0x808632c,process_archive) ->
[3, alloc] (0x80ad974,make_qualified_name) -> [4, free] (0x808663a,process_archive) ->
[5] (0x808620b,process_archive) -> [6, use] (0x80ab86a,error)
我们提供了一个模糊测试脚本模板，带有若干输入参数，例如要运行的模糊器、超时时间（分钟）以及预定义目标（例如，从漏洞报告中提取）。对于上述示例，我们使用脚本 CVE-2018-20623.sh 并运行 UAFuzz：
# 运行 UAFuzz，超时 60 分钟
$UAFBENCH_PATH/CVE-2018-20623.sh uafuzz 60 $UAFBENCH_PATH/valgrind/CVE-2018-20623.valgrind
在模糊测试超时后，UAFuzz 可以识别哪些输入按顺序覆盖了预期 UAF 漏洞跟踪中的所有目标位置（例如，以 ',all' 结尾的输入名称）。因此，UAFuzz 仅对这类可能触发所需漏洞的输入进行分流，方法是使用现有性能分析工具（如 Valgrind 或 AddressSanitizer）。
我们使用 GNU Patch 的 CVE-2018-6952 来说明生成不同且独特的漏洞触发输入以促进修复过程的重要性。GNU Patch 存在一个重复释放漏洞，已被开发者修复（提交 9c98635）。然而，利用 CVE-2018-6952 的堆栈跟踪，UAFuzz 发现了最新版本 2.7.6（提交 76e7758）中一个不完整的修复漏洞 CVE-2019-20633，其漏洞跟踪存在细微差异。总体而言，该过程与漏洞复现应用类似，不同之处在于可能需要手动识别目标 UAF 漏洞跟踪。我们使用现有漏洞的 PoC 输入和 fuzzing-corpus 中的有效文件作为高质量种子。
# 模糊测试 CVE-2018-6952 的补丁版本
$UAFBENCH_PATH/CVE-2019-20633.sh uafuzz 360 $UAFBENCH_PATH/valgrind/CVE-2018-6952.valgrind
一种可能的混合方法是将 UAFuzz 与 GUEB 结合，GUEB 是目前唯一用 Ocaml 编写的用于 UAF 的二进制级静态分析器。然而，GUEB 会产生许多误报，并且目前无法正确处理复杂二进制文件。因此，我们目前正在改进 GUEB 并将其集成到 BINSEC 中，然后使用从 GUEB 报告中提取的目标来引导 UAFuzz。敬请期待！