USENIX 2021-The Use of Likely Invariants as Feedback for Fuzzers

摘要

虽然模糊测试被证明是发现软件缺陷的一种非常有效的技术，但开放性挑战仍然存在。它的一个主要局限性是，流行的覆盖率引导设计经过优化，可以覆盖受测程序的不同部分，但当仅可访问性不足以触发漏洞时，这种设计会遇到困难。实际上，许多bug需要一个特定的程序状态，该状态不仅涉及控制流，还涉及一些程序变量的值。不幸的是，过去提出的用于捕获项目状态的替代勘探策略在实践中几乎没有帮助，因为它们会立即导致状态爆炸。
在本文中，我们提出了一种新的反馈机制，通过考虑程序变量之间的常用值和关系来增加代码覆盖率。为此，我们在基本块级别学习了大量不变量，并相应地划分了程序状态空间。我们的反馈可以区分输入何时违反一个或多个不变量并奖励它，从而重新定义代码覆盖率通常提供的程序状态近似值。
我们在名为INVSCOV的原型中实现了我们的技术，该原型是在LLVM和AFL的基础上开发的。我们的实验表明，相对于使用纯代码覆盖率反馈的模糊器，我们的方法可以发现更多不同的bug。此外，他们还发现了一个每天在OSS Fuzz上测试的库中的两个漏洞，目前仍然存在于最新版本中。

内容

问题：事实上，只有当i.)程序执行达到给定的指令，ii.）应用程序的状态满足某些条件。在极少数情况下，状态没有条件，因为LAVA-M[22]数据集中的大多数错误都是人工创建的，只需到达目标应用程序中的某个点即可触发[38]。一方面，这一方面非常重要，因为使用代码覆盖率来奖励探索结果，而事实上模糊者没有任何动机来探索已经观察到的一组控制流事实（例如分支及其频率）的更多状态。因此，对于现有工具来说，检测涉及程序状态复杂约束的bug要困难得多。另一方面，奖励探索新状态的模糊者（状态覆盖率）的简单解决方案也是一个糟糕的策略，这往往会增加错误检测率。这是因为，对于非平凡的应用程序，可能的程序状态数通常是无限的。
现代模糊程序在探索程序状态时所遇到的挑战，即使是对于不需要困难的编程条件的代码也是如此。最先进的CGF系统可以在覆盖率达到饱和的同时，仍然会在运行中遇到的程序点上丢失bug。此外，他们可能无法生成测试用例来覆盖看不见的程序点，只要这些程序点仅在满足不单独依赖于控制流的条件时才可到达。

解决思路：因此，需要使用特殊的技术将程序状态简化为更易于管理的状态，以便在测试期间进行探索，同时仍然保持模糊程序触发潜在错误的能力。迄今为止，很少有作品试图找到这样的折衷方案。例如，一些模糊器通过使用更敏感的反馈来近似程序状态，例如使用调用堆栈信息丰富的代码覆盖率，甚至使用从内存加载和存储的值。第二种方法，如[79]所示，通过不仅考虑控制流，还考虑程序状态中的值，更好地近似程序状态覆盖率，但效率较低其他人更容易发现bug，因为它会导致上述的状态爆炸问题。为了获取更丰富的状态信息，同时避免状态爆炸问题，研究人员还研究了人工辅助解决方案。例如，FUZZFACTORY[60]允许开发人员定义他们特定于领域的目标，然后添加路径点，当生成的测试用例朝着这些目标前进时（例如，当两个比较操作数中有更多的位相同时），这些路径点会奖励fuzzer。在撰写本文时，最成功的近似程序状态覆盖率是通过仅针对由人类专家选择的某些程序点来实现的，如[4]中最近提出的。在这项工作中，部分状态空间被手动注释，反馈函数被修改以更彻底地探索这类空间。我们相信，这一过程的自动化可能是该领域未来研究的一个重要课题。

我们的做法：在本文中，我们为模糊测试提出了一种新的反馈，该反馈除了考虑代码覆盖率外，还以完全自动化的方式考虑程序状态的一些有趣部分，并且不会引起状态爆炸。其关键思想是利用与“常用”变量值的局部差异信息来增强边缘覆盖率——模糊器使用的最广泛和最成功的代码覆盖率度量。为此，我们通过执行输入语料库（如从先前CGF活动中提取的队列）并在所有观察到的执行中学习对这些变量的值和关系的约束，来挖掘程序变量的可能不变量。需要注意的是，基于执行的不变挖掘产生的约束不一定是程序属性的模型，而是分析输入语料库的局部特征[25]：因此，在不同的输入下可能会违反约束。我们的直觉是，这些局部属性