优秀的模糊测试代码是如何炼成的？

所谓模糊测试，是指一种通过向目标系统提供非预期的输入并监视异常结果来发现软件漏洞的方法，它经过了近 20 年的发展，早已在程序员圈中成为一种主流漏洞挖掘技术。基于此，开发者们该如何编写良好的模糊测试代码？

作者 | John Regehr

译者 | 弯月，责编 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下为译文：

模糊测试（Fuzzing）是发掘漏洞和其他软件缺陷的强力手段，但通常开发者都是利用这种方式来深入发掘已部署代码中的问题。实际上，我们应该尽早完成模糊测试，而且开发人员应该花点时间来编写更易于开展模糊测试的代码。

在这篇文章中，我想介绍一些方法，告诉你如何编写更方便模糊测试的代码。但这些方法并不全面，而且各个方法之间也可能有重叠。纵观本文，我会使用“模糊器”来指代所有类型的随机测试用例生成器，无论是基于突变的（afl、libFuzzer等）还是生成的（jsfunfuzz、Csmith等）生成器。注意，本文提出的建议并非适用所有情况，但其中很多都是合理的软件工程建议。我会用粗体标明一些我认为特别重要的观点。

在测试预言上下功夫

测试预言（test oracle）决定了测试用例是否会触发bug。在默认情况下，afl等模糊器唯一可以使用的预言就是操作系统的页面保护机制。换句话说，它只能检测系统的崩溃。但是我们能做到远不止于此。

断言和由编译器插入的sanitizer检查是另一种类型的预言。在模糊测试中，你应该尽可能多地使用这种类型的检查。除了这些简单的预言之外，还有很多其他的预言，例如：

函数与反函数：解析与输出的闭环、压缩与解压缩的闭环、加密与解密的闭环及其他类似的代码是否会按预期正常工作？

差异：两个不同的实现或同一个实现的两种不同的模式是否表现出相同的行为？

变形：如果在保证语义的情况下修改测试用例，系统是否会表现出的行为，例如在表达式中再添加一层括号？

资源：处理输入时，系统消耗的时间、内存等是否合理？

特定领域：例如，一个因压缩而导致画质受损的图像在视觉上是否与未压缩的图像一致？

我们值得花时间和精力建立强大的预言，因为它们往往能够发现应用程序级的逻辑错误，而通常我们通过查找数组越界等方式只能捕获低级的错误。

几年前，我撰写过一篇有关于该话题的文章（https://blog.regehr.org/archives/856）。有一个Twitter用户建议：“在测试解析器的时候，你必须检查它返回的对象，而不仅仅是检查解析这个动作的执行。”这是一个很好的建议。

干预I/O与状态

无状态代码更方便展开模糊测试。但除此之外，你还需要API来控制状态和干预I/O。例如，如果程序需要从操作系统中获取核心数、当前日期或剩余磁盘空间量等信息，那么你应该提供一种设置这些值的方法并写在文档中。我并不是说，我们需要随时改变核心数量，而是我们可能在单核模式下针对代码展开模糊测试，然后还需要在128核模式下再进行一次模糊测试。有些控制状态和I/O的方法非常重要，比如简化重置状态（为了支持持久模式的模糊测试），并避免会导致非确定性执行的隐藏输入等。在针对代码进行模糊测试时，我们希望拥有尽可能多的确定性。

避免或控制模糊测试的阻碍

模糊测试的阻碍就是那些无法模糊化的东西。典型的模糊测试阻碍是包含在输入中某处的校验和：基于突变的模糊器随机修改输入会导致校验和不合法，从而降低代码覆盖率。这个问题基本上有两种解决方案。第一种，在模糊测试构建中关闭校验和验证；第二种，确保模糊器能够生成带有合法校验和的输出。基于生成的模糊器自带这种功能；如果使用基于突变的模糊器，那么我们需要编写一个小工具，在生成测试用例后，我们需要赶在测试用例传递给模糊测试程序前，给测试用例加上有效的校验和。alf支持这种方法。

除了校验和之外，难以满足的输入验证属性也是一个严重的问题。例如，如果你要针对强类型编程语言的编译器进行模糊测试，那么盲目地修改编译器的输入很难获得有效的编译器输入。我喜欢将有效性的约束分为软约束（无效输入除了浪费时间外，并没有其他害处）和硬约束（系统在处理无效输入时可能会暴走，因此必须避免无效输入，否则完全无法进行模糊测试）。如果我们通过针对C++编译器开展模糊测试来寻找错误代码中的bug，就会面临硬有效性约束，因为会导致未定义行为的编译器输入看上去很像是代码中有bug。对于这类问题，我们没有简单的通用解决方案，只能通过一系列技巧来考虑有效性属性。有一个最简单的解决方案（但往往不是正确的解决方案），那就是自己编写一个模糊器。但问题在于，如果自己编写模糊器，就无法再利用现代覆盖驱动的模糊测试技术——这种技术非常了不起的。为了匹配覆盖率驱动的模糊测试框架，你有以下几种选择：首先，编写一个能够满足有效性约束的自定义变异器；其次，采用了解结构的模糊，意思是说从模糊器中获取修改后的数据，并将其转换为模糊测试程序所需要的内容。关于如何让覆盖驱动的模糊器在有效性约束下依然良好地运行，且不需要大量的手动工作，我们还有大量的研究工作需要展开。这其中涉及很多细节，改日再深入介绍。一般来说，在模糊器中加入类似SAT的求解器并不能解决这个问题，其原因首先是，有的有效性约束（比如校验和）对于求解器来说难度特别大；其次是因为有些有效性约束（如C++程序中的未定义行为）是隐含的，我们无法从系统中推断，甚至从原理上也不可能。

一般来说，你无法通过为公共API提供输入的方式，来针对系统的大部分代码进行模糊测试，因为这些访问会被系统中的其他代码阻止。例如，如果你使用自定义的内存分配器实现或自定义的哈希表实现，那么应用程序级别的模糊测试可能无法针对分配器或哈希表进行有效的模糊测试。这些API应该直接暴露给模糊测试。单元测试和模糊测试有强烈的联系：如果其中一个可行且可取，那么另一个也应该差不多。通常你应该同时兼顾两者。

通常，Sanitizer和模糊器需要对构建过程进行调整，甚至是重大的改动。为了简化这一过程，请尽可能简化构建过程。确保可以轻松切换编译器以及修改编译器选项。尽量减少对特定工具（以及工具版本）的依赖。定期利用多个编译器构建和测试代码。构建系统的特殊依赖都需要记录下来。

为覆盖驱动的模糊器排除障碍

由于覆盖驱动的模糊器的主要精力放在了测试未覆盖的分支上，因此可能会被特殊的方式阻碍。例如，如果覆盖驱动的模糊器遇到了太多未覆盖的分支，它就会在这些分支上花费大量时间，导致覆盖程序其他分支的可能性降低。例如，有一次我比较了一个程序在使用和不使用UBSan两种情况下的afl覆盖率，结果发现（在我设定的时间限制下）sanitized程序的覆盖率要比没有sanitized的程序低得多。但另一方面，我们也希望模糊器能找到sanitizer的错误。我的建议是有sanitized和没有sanitized的程序都进行模糊测试。我不知道应该如何为这些模糊测试活动分配资源，也不知道是否有人在研究这个问题。也许这个问题并不重要，因为模糊测试本来就是过度测试。

有时候，你的程序在执行前期调用的代码会包含大量分支且会被过度模糊的代码。例如，可能你需要在处理输入之前对输入进行解压缩或解密。这很可能会影响基于覆盖的模糊器，导致模糊器花费大量时间去模糊测试加密库或压缩库。如果你不是希望这样，那么就应该提供一种方法，在模糊测试过程中禁用加密或压缩。

程序中的解释器都可能会给基于覆盖的模糊器造成困难，因为相关的程序执行路径是在解释器数据中编码的，而对于模糊器而言，一般情况下数据是不透明的。如果你想让基于覆盖的模糊器发挥最大作用，那么就应该考虑避免编写解释器，或者至少大力简化解释器。解决嵌入式解释器有一个很明好的方法（我相信肯定有人尝试过，不过我不知道）就是提供一个API，告诉模糊器该如何观察被解释语言的覆盖率。

支持高吞吐量的模糊测试

模糊测试对于高吞吐量的系统最有效，特别是对于基于反馈的模糊器而言，这种模糊器需要一定时间来学习怎样才能测试难以覆盖的目标。有关吞吐量的一个简单技巧是：提供禁用慢速代码（例如详细日志）的方法。类似地，干预I/O可以让我们不需要借助运行速度技巧，比如在内存盘上运行模糊器等方法。

“但我希望模糊我的代码变得更难，而不是更容易”

我不太赞同这个观点。我们不应该期待模糊代码来保证安全，而应该采用以下方法：

尽早、尽可能彻底地实施模糊测试，在将代码发布到外部之前消除模糊测试能够发现的缺陷。

通过人见人爱的强类型系统的编程语言编写代码——这可以静态地消除由于错误的编程习惯造成的问题，例如可以防止我们将错误的东西放入哈希映射。

积极地使用断言和sanitizer来动态检查类型系统无法静态强制执行的属性。

反模糊技术的确存在，但我不认为它代表软件朝着更好的方向发展。

总结

随机测试非常强大，我们理应善加利用：如果你不针对你的代码展开模糊测试，那么别人也会。本文向软件开发人员介绍了一些实施模糊测试的好方法。当然还有很多其他方面本文未能提及，比如选择一个优秀的语料库以及编写一个良好的模糊驱动程序。

原文：https://blog.regehr.org/archives/1687

本文为 CSDN 翻译，转载请注明来源出处。

【END】

热 文推 荐