知识普及：关于Fuzzing模糊测试入门原理及实践的讨论

狩猎者网络安全旗下——知柯信息安全团队（知柯信安）

漏洞挖掘是否是真正的安全呢？

"The best alternative to defense mechanisms is to find and fix the bugs."

grescurity的观点是安全缓解
ACTUAL effective improvements to security come from building mitigations to kill entire classes of vulns, not bug hunting." Maybe we need secure language, library and tools – security by design.

什么是Fuzzing(模糊测试）？

模糊测试（Fuzzing），是一种通过向目标系统提供非预期的输入并监视异常结果来发现软件漏洞的方法。[百度百科]

模糊测试（fuzz testing, fuzzing）是一种软件测试技术。其核心思想是将自动或半自动生成的随机数据输入到一个程序中，并监视程序异常，如崩溃，断言（assertion）失败，以发现可能的程序错误，比如内存泄漏。模糊测试常常用于检测软件或计算机系统的安全漏洞。

模糊测试最早由威斯康星大学的Barton Miller于1988年提出。他们的工作不仅使用随机无结构的测试数据，还系统的利用了一系列的工具去分析不同平台上的各种软件，并对测试发现的错误进行了系统的分析。此外，他们还公开了源代码，测试流程以及原始结果数据。

模糊测试工具主要分为两类，变异测试（mutation-based）以及生成测试（generation-based）。模糊测试可以被用作白盒，灰盒或黑盒测试。[3]文件格式与网络协议是最常见的测试目标，但任何程序输入都可以作为测试对象。常见的输入有环境变量，鼠标和键盘事件以及API调用序列。甚至一些通常不被考虑成输入的对象也可以被测试，比如数据库中的数据或共享内存。
对于安全相关的测试，那些跨越可信边界的数据是最令人感兴趣的。比如，模糊测试那些处理任意用户上传的文件的代码比测试解析服务器配置文件的代码更重要。因为服务器配置文件往往只能被有一定权限的用户修改。
【维基百科】

Fuzzing的历史：

“Generates a stream of random characters to be consumed by a target program”
– Miller et al.

1988年，威斯康星大学的Barton Miller教授率先在他的课程实验提出模糊测试。实验内容是开发一个基本的命令行模糊器以测试Unix程序。这个模糊器可以用随机数据来“轰炸”这些测试程序直至其崩溃。类似的实验于1995年被重复，并且包括了图形界面程序，网络协议和系统API库。一些后续工作可以测试Mac和Windows系统上的命令行程序与图形界面程序。

技术：

模糊测试工具通常可以被分为两类。变异测试通过改变已有的数据样本去生成测试数据。生成测试则通过对程序输入的建模来生成新的测试数据。

定义Definition：

我们在设计程序时，除了考虑到程序功能之外，是否会出现其他程序员无法考虑到的情况？比如安全上的问题。
Fuzzing is the execution of the PUT using input(s) sampled from an input space (the “fuzz input space”) that protrudes the expected input space of the PUT.
Fuzz testing is the use of fuzzing to test if a PUT violates a security policy.

优化问题Optimization problem

Fuzzing模型是一个优化问题

过程Process：

返回的B是返回的错误，C是测试的程序。整个Fuzzing测试最核心的一部分是Schedule调度，通过调度生成输入集。

Components组件：

1.Corpus语料集
2.Generator
3.Mutator
4.Input
5.Stage
6.Executor
7.Observer
8.Feedback

Generator与Mutator生成语料集，Mutator是改变语料集，Input是生成的语料集，Stage与Executor是模拟程序执行过程，我们将通过Observer获取执行信息，FeedBack判定语料集的过程。

Fuzzing入门教程An entry-level tutorial：

1.选择目标
2.分析代码
3.Write the harness
4.准备前奏
5.动态调优
6.Fuzzing的停止
7.Triage

选择目标

不受信任的输入：设备模块与迁移模块
非交互式、无状态：libpng与smtpd
不安全语言：C与Rust
古老而无路径：GNU coreutils与OpenSSL
单进程：libxml2与ftpd

分析代码 Analyse the code

我们的输入类型是什么？Argv、stdin、env、shm等。
它在哪里？Main, routine, lib, etc.
程序入口在哪里？
In-memory snapshot & copy
我们可以（手动）重置状态吗？
具有较少分叉的持久模式
我们应该修补和追踪吗？
Socket, checksum, timer, random

Write the harness (partial)

这是AFL模糊测试工具的部分Write the harness源代码

int main(int arg,char **argv){const char program_name[]="program name";const size t program_name_size=sizeof (program_name);static char stdin read[1024 * 16]={'\0'};static char *ret[1024 *4] = {{char * }NULL};for (size t i =0 ; i<program_name_size;i++)stdin read[i] =program_name[i];argc = 1;ret[0] = &stdin read[0];argv  = &ret[0];/*API init*/#ifdef AFL HAVE_MANUAL CONTROLAFL_INIT();#endif
}
#ifdef AFL_HAVE_MANUAL CONTROL
//must be after  AFL_INIT and befor AFL_LOOP
unsigned char *fuzz buf = AFL_FUZZ_TESTCASE_BUF;
#endif
#ifdef AFL_HAVE_MANUAL CONTROL
while(AFL_LOPP(10000)){#endif
memeset(&stdin read[program_name_size],0,sizeof(stdin read)-program_name_size);
memset(&ret[1],0,sizeof(ret) - sizeof(ret(0)));
#ifdef AFL_MANUAL_CONTROL
//don't use the macro directly in a call!
#endif
if(fuzz buf_len >sizeof(stdin_read)-program_name_size)
return 1;
memcpy(&stdin_read[program_name_size],fuzz_buf,fuzz_buf_len);

准备前奏Prepare the prelude

**Dict: man 1 expr → “\x20”, “|”, “&”, “!”, “=”, “>”, “<”, “/”, “\”, “:”, “*”, etc.
Seeds: “1 + 3”, “length 1x3”, “10 / 2”, “1234 : 23”, “sad % 3”, etc.

需要Fuzz程序源代码：

执行脚本Scripts:$ afl-system-config$ CC=afl-clang-lto CXX=afl-clang-lto++ RANLIB=llvm-ranlib AR=llvm-ar ./configure$ AFL_USE_UBSAN=1/AFL_USE_ASAN=1/AFL_HARDEN=1 make -j$(nproc)$ afl-fuzz -i seed -o out -x expr.dict  -m none -M main0 ./expr_asan$ AFL_IMPORT_FIRST=1  AFL_NO_UI=1 afl-fuzz -i- -o out -L 0 -x expr.dict -S slaveX ./expr$ # etc.

动态调优Dynamic tune：

Coverage: Gcov, llvm-cov, etc.
Performance: Linux perf, gperftools, etc.

Fuzzing的停止When to stop?

Triage

我们希望POC越小越好
最小化：
Afl-tmin, afl-extras, afl-ddmin-mod, abstract, etc.
重复数据消除Deduplication:
Afl-cmin, Stack Backtrace Hashing, Semantics-aware, etc
Exploitation：
GDB extension ‘exploitable’, etc.
Understandability：
Afl-analyze, etc.

What did we get?

CWE-125, Out-of-bounds Read:

  $ expr 0 : "\\(0*\\)*0*\\1"

CWE-787, Out-of-bounds Write:

  $ expr 0 : "\('\)*"

Fuzzing devices in QEMU

QEMU Device Fuzzer

具体来讲我们是对QEMU中的IO设备进行Fuzz

QEMU Device Fuzzer

QTest是QEMU的重置框架。

CCS 17’ - Designing New Operating Primitives to Improve
Fuzz the E1000 Network Interface Card – 4 hours

我们观察到两个问题。

1.有效操作码过低，这将影响变异和执行的速度。
我们发现写的操作（MIMO write与PCI configure write）影响较大。
我们为不同的操作码分配不同的权重-负值删除需要抑制的无效操作码和操作。在fork（2）之前，我们计算输入的总重量，以决定是否值得fork或只是返回fuzzer。

Struct Aware - Libprotobuf-mutator, AFLSmart, NAUTILUS (Sweat and blood)
USENIX Security '19 - MOPT: Optimized Mutation Scheduling for Fuzzers
我们能不能通过语法描述直接生成？

Google通过fuzzing集群对程序进行程序测试最后通知开发者。

漏洞和BUG：

[Patch] SPICE/libspice-server: Fix nullptr dereference in red-parse-qxl.cpp
[Vulnerability Disclosure] FFmpeg/libavcodec: Double free hevc context
[Vulnerability Disclosure] GNOME/libgxps: Mishandle NULL pointer in the converter
[Bug Report] qemu-system virtio-mouse: Assertion in address_space_lduw_le_cached failed
[Bug Report] GNU Coreutils: Heap underflow when expr mishandles unmatched (…) in regex
[Vulnerability Disclosure] QEMU/Slirp: OOB access while processing ARP/NCSI packets

Fuzzing的未来发展：

现在最大的问题是，Fuzzing找到了许多漏洞，目前像Google等公司具有较完整的Fuzzing流程，它们虽然能够发现自己产品的漏洞，但是没有开发者会去理会，过几天，一个白帽子会提交申请会说我们找到了一个漏洞，按照管理应该给他发证书奖品，如果每一个程序都被发现，那么SRC平台和公司的开销会变得比较大。现在的问题是，如何让开发者重视安全测试。我们如何设计Fuzzing方案？我们是否能通过静态分析的手段选择方案？能否动态地让人参与动态覆盖度的过程，让人更方便的添加语料集。

本文参考：

TSE 2019: The Art, Science, and Engineering of Fuzzing: A Survey
https://media.ccc.de/v/rc3-699526-fuzzers_like_lego
https://zh.wikipedia.org/wiki/%E6%A8%A1%E7%B3%8A%E6%B5%8B%E8%AF%95
哔哩哔哩Fuzzing入门-原理与实践