G.O.S.S.I.P 阅读推荐 2023-11-08 Fuzz Anything

今天分享一篇来自Tencent Security Big Data Lab 和UC Davis研究人员合作发表的CCS 2023论文——Hopper: Interpretative Fuzzing for Libraries：

模糊测试技术在最近几年已经证明它是最有效的漏洞挖掘手段，但是由于模糊测试受限于需要给目标对象人工构造测试入口(Fuzz driver) ， 仍有非常多的代码（包括项目、API等等）没有被模糊测试所覆盖。

下图给出了11个C/C++库中，接口的模糊测试覆盖情况，可以看到，尽管这些库在各种软件和系统中作为基础设施被广泛地应用，然而他们的开发者只为少部分的API编写了模糊测试驱动(fuzz driver)。

究其原因，是因为要写出高质量的fuzz driver实在是太麻烦了。人工编写的library fuzzer (Manually Crafted Fuzzers, MCFs) 通常需要开发者对待测的库有深入的理解，编写出逻辑正确且覆盖率高的fuzz drivers 需要不少的工作量。

为了解决这一现状，最近的研究者提出了一些自动化的替代方案，大体可以分为基于学习的方法以及基于模型的方法，但是这些方法无外乎依赖于既有的代码用例或者用户预定义的输入来获取自动化生成fuzz drivers所需要的信息。这样的方法既没有摆脱人力的介入，还引入了一些其他不可控的输入源来影响测试的效果。因此到目前为止，library的模糊测试仍然严重依赖人工构造的测试入口。

就像现在大家寄希望于AIGC来解放我们的生产力的同时，我们也梦想能够有一天在模糊测试library时不需要让安全开发人员疲于编写测试入口。 甚至我们可以大胆点，完全舍弃fuzz drivers，让Fuzzer可以直接生成待执行的程序，从而达到自动测试任意共享库API的目标。为此，我们提出了 Interpretative Fuzzing 来完全零人工地学习和测试library API。我们提出的Interpretative fuzzing主要由两个部分组成：一个轻量级的解释器和一个grammar-aware fuzzer。二者通过一个自定义的Domain-Specific Language（DSL）交流连接。Fuzzer生成具有DSL语法的输入，包含调用的API及其参数。解释器和被测试的library链接在一起，可以解释DSL，并执行对应的API。根据解释器的执行反馈，生成器可以推断约束、持续优化下一轮生成的DSL输入。

作为面向库的模糊测试工具，Hopper所需要的输入包括待测库的头文件以及共享库的二进制文件。通过对头文件的解析，Hopper可以得到关于API的签名以及类型的详细定义；而grammar-aware fuzzer以及解释器，则是通过将Hopper运行时框架与插桩后的共享库二进制文件链接后得到的。

为了让fuzzer可以生成足够复杂的程序来触发隐藏在待测库中的程序缺陷，Hopper采用了一种两阶段的程序生成方法。在pilot phase我们根据API描述生成最简单的API调用，在Evolution阶段我们选择已有的种子输入，对其进行变异生成更多不同的API调用。

Pilot phase

在这一阶段，fuzzer会尝试根据头文件中的签名信息来为待测API组装出简单的测试程序。根据API参数类型的不同，fuzzer会选择直接生成（基本类型或者定义完整的复合类型）或是从其他API的返回值中获取（不透明指针或空类型指针）。下图是一个简单的例子，测试的目标是void foo(Bar bar)。如果生成的程序触发了新的代码覆盖，那么就把这个程序添加到Hopper的语料库(corpus)中。在例子中，为了方便大家理解，我们使用C的语法来表示fuzzer生成的程序，而不是Hopper的DSL。

Evolution phase

在这一阶段，Hopper会依次从语料库中取出先前保存的程序，并对它们进行一些变异（mutation）操作，如果变异后的程序触发了新的代码覆盖，则将变异后的程序保存到语料库中。受益于fuzzer对语法的理解能力，Hopper中实现了基于类型感知的值变异策略(type-aware value mutation)以及针对调用语句的变异策略(call statement mutation)。在下图的例子中，Hopper为测试的目标函数引入了一个与它共享同一参数的函数调用语句作为变异。

有了以上的架构和流程设计，Hopper已经能够生成足够复杂的程序了。但这并不是interpretative fuzzing的全部。完全随机的程序生成实际上是毫无意义的。在实践中，库API通常具有严格的API内约束以及API间约束。举个例子，我们不能仅仅因为size_t strlen(char *str)函数在参数为空指针时会抛出SIGSEGV就认为这个函数的实现是有缺陷的——使用API之前，必须满足所规定的输入约束。

所以，我们还为Hopper引入了完全自主的约束学习能力。为此，需要对解释器的反馈收集能力进行一些扩展，增加的功能包括：任意API分支追踪能力（optional branch tracking），上下文敏感的代码覆盖信息（context-sensitive code coverage），溢出检测（overflow-detection）以及崩溃信息收集（crash report feedback）。基于此，我们将Hopper在evolution phase的工作流程扩展为：

概括地来讲，一旦解释器遇到了一个crash，那么会将和crash相关的信息发回给fuzzer，fuzzer内的约束学习模块会对这些信息进行分析并推导出对应的约束，这些约束将用于纠正fuzzer生成的错误的输入程序。

在Hopper中，API内约束包括：

• 指针非空（NON-NULL）

• size_t strlen(const char *str)

• 有效文件资源（FILE）

• FILE *fopen(char *file_name)

• 特定值（EQUAL）

• int snprintf(char *s, size_t n, const char *fmt, …)

• 受限区间（RANGE）

• char *get_element(char *buf, int index)

• void *malloc(size_t size)

• 数组长度（ARRAY-LEN）

• char *itoa(int value, char *string, int radix)

• 指定类型转换（CAST）

• void *memcpy(void *dest, const void *src, size_t num)

以非空指针为例，Hopper会收集崩溃程序的反馈信息，如果程序抛出了SIGSEGV的信号，并且导致崩溃的内存地址是一个接近0的值，那么Hopper就认为这一崩溃是由一次空指针访问引起的。而如果此空指针是Hopper自身生成的空指针，那么我们就为这个空指针对应的参数添加一个指针非空（NON-NULL）约束，避免对此参数生成空指针。

考虑到不同库之间上下文的多样性，我们无法对API间的约束给出一个精确的定义，而是换了一种思路：如果生成或是变异后的程序恰巧捕捉到了某一种API间的特殊关系（触发了新的代码覆盖），那么就将这个程序保存到我们的语料库中。此外，Hopper还会分析出引入新的代码覆盖的具体API参数，然后针对该参数对程序进行切片，将与该参数相关的所有语句保存在一个“有效参数”(effective argument)的语料库中，以供下一次需要为API生成对应类型的参数时复用。

我们在11个广泛使用的真实C/C++库上测试了Hopper，测试的对象包括cJSON, c-ares, libpng, lcms, libmagic, libpcap, zlib, cre2(re2的C程序封装)，sqlite3, libvpx以及libaom。每一组测试设定为24小时，重复实验5次并对结果取平均值。所有的测试都绑定在单核上运行。我们将Hopper的测试结果与相同条件下，MCFs，FuzzGen和GraphFuzz的结果进行了比较。评估的标准主要包含3个维度：代码覆盖率，bug发现以及习得约束的正确性和有效性。

代码覆盖率：

Bug发现：

约束有效性：

约束正确性：

最后打个广告：我们也就是Tencent Security Big Data Lab在招聘实习生（1名）参加Hopper的开发，有兴趣的同学可以联系我们！

联系邮箱：[email protected]

---

论文：https://arxiv.org/pdf/2309.03496
代码：https://github.com/FuzzAnything （欢迎大家star）

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2023-11-08 Fuzz Anything