摘要

高扩展性和低运行成本使得模糊测试成为发现软件bug的一种标准的测试方法.但是由于缺乏对fuzz的评估指标和标准,因此想要比较各个fuzzer之间的性能十分困难.Magma就是为了解决指标和基准集而生.通过检测目标程序的bug,Magma还支持收集独立于Fuzzer的以bug为中心的性能指标.

1. 介绍

Fuzzing是广泛使用的动态模糊测试工具,一个模糊测试器程序化生成输入模糊器程序化地生成输入，并使目标程序(“目标”)接受这些输入，目的是触发故障(例如，发现bug)。Fuzzing本质上是一个合理但不完整的bug查找过程(给定有限资源).fuzzing技术的成功导致了新技术的大量涌现.但是现有的绩效指标的缺陷要求对模糊测试评估进行重新的思考,现有绩效指标的缺陷要求对模糊评估实践进行重新思考。特别是，在这些评估中使用的性能度量必须准确地度量模糊器实现其主要目标的能力:发现bug。同样，用于评估模糊器如何满足这一目标的目标必须是现实的，并表现出不同的行为。这使得从业者有信心在实际环境中部署一种模糊技术时会产生改进。
为了满足这些标准,Magma作为建立在真实程序上的bug被推选了出来.Magma包括了大量广泛使用的开源库与开源应用.对于每个Magma的工作文件夹,我们手动分析安全相关的bug和补丁.把这些有缺陷的代码重新插入这七段程序中去.这样便可以从多维度来评价fuzzer的工作情况.3我们做出了以下的贡献:

• 建立以发现bug为中心的基准指标并且可以对模糊器进行公平准确的评价.
• 与现有模糊基准的定量比较
• Magma对七种广泛使用的模糊测试器的评价

2. 背景和动机

此章节介绍了fuzzing作为一种软件测试技术,以及新的fuzzing技术如何与已经存在的fuzzing技术进行比较.本文的目标是激发新的模糊测试器的评价需求.

2.1 fuzz测试

fuzz是一种自动测试的技术,可以对目标程序生成大量的输入,这些输入可以引起目标程序的崩溃.重要的是,这些输入结果依赖于对fuzzer对目标程序输入格式与程序结构的了解.Fuzzer是根据他们对目标程序的结构而分类的.

2.2 目前fuzzer的评价体系

随着fuzz新技术的快速提升和出现,这意味着不同fuzzers之间要快速比较,以此来论证新的fuzz工具要比以前的fuzz工具更加的优秀.为了更加公平和精确的fuzz评价,模糊测试在适当的基准集上进行显得至关重要.fuzzer的评价标准有以下的内容

• 性能指标: 如何对fuzzer进行评价和比较
• 测试目标: 需要被模糊测试的软件,这个软件应该是多样且现实的,这样测试者才能够在真实环境中测试
• 种子的选择: 单个模糊测试的长度在多轮的重复实验和评估中也应该保持连贯.
• 实验持续时间: 单个模糊测试的时间长度也应该在重复训练与被测试的fuzzer之间保持连贯性.
• 训练的数目: 模糊测试的高度随机性需要有大量的重复的实验,并且要对结果进行合理的比较.

2.2.1 Fuzzers通常根据一组目标来进行评估,这些目标来自以下的基准集,基准集目前在Table1中.

本节主要论述了其他评测工具的不足

• LAVA-M的测试集(建立在coreutils-8.24之上)旨在通过不同的执行路径注入bug来评估fuzzer的探测能力.然而,LAVA的bug只能注入单一的,相同的类型.这些bug类型不能够精确的表示真实软件运行过程中遇到的错误.
• BugBench和Google的测试集都有包含真实bug的程序,但是所含有的bug数量很小,因此不太适合模糊器的评估
• Google FuzzBench只是依赖单一的覆盖情况来作为指标.UNIFUZZ跟Magma同时开发,但是缺乏基础并且不知道每一个target包含有多少个漏洞.
• OSS 虽然使用了现实中的软件,但是因为缺乏挖掘bug的基本能力,所以不能提供精确的,定量的评估

以下各个Fuzz的截图指标:

2.2.2 崩溃可能是由程序中的架构冲突(例如:例如，零除法、非映射/非特权页面访问)所产生.

想要知道正确的程序模型是一件非常困难的事情,因此需要常常导致错误检测的不完全以及识别的不精确.

3. 所需要的基准集属性

在设计基准集的时候有几个要素必须加以考虑:relevance;reproducibility; fairness; verifiability; and usability, 虽然围绕这些属性建立基准集已经取得了很好的研究成果,但也带来了挑战.可重复性,CPU的基准都需要被考虑.所以基准测试集必须存在以下的特性:

• **多样性:**基准及必须包含和真实环境相同的错误.
• 可验证: 基准集必须产生可验证的指标
• 可用性: 基准集可以任意访问

3.1 多样性

一个基准集必须包含各种各样的bug和程序.目前流行的几款基准集都不合适.

3.2 可验证

基准集应该提供一系列已知的错误,可以通过理论来验证.

3.3 实用性

4. Magma的方法

简而言之,Magma数据集满足之前讨论的所有的基础条件.对于每一项工作,我们可以手动的检测适合Magma的bug和漏洞报告.对于这些错误,我们可以通过名为forward-porting的方式将每一个bug注入到最新版本的程序中.Magam中还植入了源码检测工具来收集fuzzer触发bug的能力.Magma可以在fuzz运行时同时监控数据,这些数据可以用来评价fuzz的性能.Fuzzer的评价建立在它到达,触发,检测bug的时间.Magma提供了一种紧急模式,在此模式下,Magma一旦满足条件就会中止.

4.1 Target Selection

Magma包含有一下7个目标程序,如表所示:

4.2 Bug的选取和插入

Magma包含118个bug,跨越11个CWE,与存在的基准集相比,Magma是第二大的bug库,Magma可以从报告和各种版本的forward-ported上获取各种bug集合.与其他基准及相比的优势如下:

4.3 表现的测试指标

传统fuzz评价依赖于 崩溃以及bug的数目和代码覆盖率.Magma使用reaching,triggering, anddetectinga bug三个指标来衡量fuzzer

4.4 运行监控

Magma的运行监控程序可以收集实时的静态数据,如果发生未知的错误,会对新错误进行分类并添加到基准测试中去.

5.设计和实施

Magma需要一些关键的设计和选择实现,接下来我们讨论这些选择:

5.1 Forward-Porting

前向移植要求我们对原来的错误报告的错误进行还原(在现有版本的基础上),可能会提交一个或者多个错误,因此需要进行区分.

与将之后的错误移植到之前的版本相比,Forward-Porting可以保证所有已知的bug被修复,并且重新引入的bug将会有真实的意义.当然,新的代码库可能会有其他新的bug,但forward-porting可以让Magma随着每一次bug的修复而扩展.而且,未来代码更改可能会导致之前移植的bug过时.forward-porting注入bug时需要进行验证.
所有Magma的bug时手工注入的,这个过程包括以下几步:

• 寻找bug报告
• 识别影响代码的错误
• 找到相关的修复提交
• 从修复提交中确认bug的产生条件
• 收集这些条件来作为路径约束
• 将这些路径约束建模为布尔表达式
• 注入这些bug

自动注入这些bug可能会产生一些问题.为了证明手动注入的合理性,我们列举了一些范围…
当然,手动注入同样具有一些严重的问题.目前还需要进行完善.

5.2 weird status(奇怪的状态)

当莫乎其生成错误的输入,执行器执行此输入时,程序就会进入到一个非常奇快的状态.此状态收集的信息是不可靠的,因此只会收录这个状态之前和之后的信息.

5.3 静态的基准集

Magam是包含真实工作负载的静态测试集,如果这些系统在Magma上工作良好,那么在现实中也会类似.如果开发人员调整被测系统以在基准测试中表现更好，而不是专注于实际工作负载，则可能会发生过度拟合.为了防止过度拟合,Magma的forward-porting过程中允许目标程序的自我更新.

5.4 Leaky Oracles

最大化分支覆盖率的模糊器可以检测预言机的分支，从而生成满足分支条件的输入.解决这个泄露的问题的方法是生成已检测和未检测的代码的文件.检查二进制文件并且把数据报给运行监控器,这个方法不但增加了运行时的开销,还复杂化了Magma的实现.我们经常使用评估内存写入.可以通过污点分析和其它数据流分析来检测内存访问模式.

5.5 漏洞的证明

在注入bug时必须要确定bug可以被触发,这需要特定领域的知识.

5.6 未知的bug

Magma使用的真实世界的程序,所以可能存在未知的bug,fuzzer可能会可能会触发这些bug,但这种指标又不存在于Magma中,因此需要手动添加到基准测试集中.

5.7 fuzzer的兼容性

fuzzer不局限于特定的引擎,在该引擎下他们可以分析探索程序.因此对Magma评估的fuzzer加上了一下的限制,模糊器必须在 OS 进程的上下文中执行目标，并且可以不受限制地访问 OS 设施（例如，系统调用、库、文件系统）

6. 评价

6.1 方法

我们评估了好几款fuzzer,已建立我们的指标和基准集.总共有七款开源的fuzz工具.这七个fuzz工具针对每个模糊器/目标组合在十个相同的 24 小时和 7 天模糊测试活动中进行了评估。 这相当于 200,000 个 CPU 小时的模糊测试.

6.2 到达bug的时间

我们使用找到bug的时间来衡量fuzz的表现.Magma分别记录了到达和触发bug的时间,允许我们比较多维度的比较fuzz的表现.fuzz要在有限的时间里边发现错误.fuzz的高度随机性意味着相同的实验之间发现错误的时间会具有很大的差异.尽管有这些重复,fuzz也有可能在分配的时间里找不到bug,导致测量的不准确.

6.3 实验的结果

6.3.1: Bug的数量和数据的意义.

下图展示了每一个fuzz找到的bug的数量.这些值易受外部条件的影响下,妨碍我们评价fuzz的性能.因此我们收集样本集进行分析,使用 Mann-Whitney来计算p值.P 值可衡量一对样本集的差异程度以及这些差异的显着性。因为我们的结果是从独立的群体里收集.

我们如果不做任何假设,因此,我们应用Mann-whitney来衡量数据的意义. Mann-Whitney U-test 表明多数Fuzz对目标的表现相同.图4表明,在多数例子中,在大多数情况下，平均错误数的小幅波动并不显着，因此结果不够确定。

6.3.2 bug到达的时间

总的来说,在24h的活动中,118个bug中的78到达了.没有一款fuzzer触发超过37个bug

此处y轴表示bug的生存概率, 未被发现的bug占整个bug的比值