论文阅读-- UNIFUZZ: A Holistic and Pragmatic Metrics-Driven Platform for Evaluating Fuzzers （2020）
目录
摘要：
1 Introduction
2 Motivation of UNI FUZZ
挑战1 ：Usability Issues of Existing Fuzzers.
挑战2:Lack of Pragmatic（实用的） Real-World Benchmark Programs.
挑战3:Lack of Proper and Comprehensive Performance Metrics.
3 Design of UNI FUZZ
3.1 Usable Fuzzers
3.2 Pragmatic Benchmarks
3.2.2程序选择
3.3 Performance Metrics
4.Evaluations of the State-of-the-art Fuzzers
4.1 Experiment Settings
4.2 Quantity of Unique Bugs
4.3 The Quality of Bugs
4.3.1 Severity of Bugs
4.3.2 Rareness of Bugs
4.4 Speed of Finding Bugs
4.5 Stability of Finding Bugs
4.6 Coverage
4.7 Overhead
5 Further Analysis
5.1 Instrumentation Methods
5.2 Crash Analysis Tools
摘要：
该平台旨在系统性地对软件漏洞检测工具（即模糊测试技术）进行定量分析与综合评测。其中包含35种可选工具、20个真实应用程序基准测试以及六类核心性能指标作为评测依据。通过深入研究现有工具的特点与局限性后识别并修正了若干缺陷最终整合至UNI FUZZ平台内作为其核心功能之一。此外该平台还构建了一套创新性的性能评测体系从多个关键维度对各类工具进行全面考察包括精确度效率与鲁棒性等多个重要指标维度。基于此框架 UNI FUZZ对若干知名模糊测试技术进行了系统性评估结果表明目前并无单一工具能在所有测试案例中表现出色然而某些因素往往被忽视例如某些特定的技术手段与分析方法对于评测结果的影响具有重要意义这些建议也为未来开发更加可靠的模糊测试技术提供了参考依据希望这些发现能启发相关研究者探索更具潜力的基础架构从而推动模糊测试技术的整体发展
1 Introduction
现有的Fuzzing技术确实存在一些局限性包括缺少可靠的实验数据没有统一的标准测试框架以及不完整的评估指标等问题。针对这些问题开发团队开发出一个名为UNI FUZZ的开源度量驱动平台旨在帮助评估Fuzzing技术该平台具备高可用性实用性以及全面的性能评价体系。
主要贡献：
- 开发并构建了开源的UNI FUZZ平台，并提供了一整套用于系统性地评估35种主流fuzzer性能的方法。该平台不仅附带了构建Docker容器的脚本，并集成有20个真实场景程序的基准测试库以及6类关键性能指标，并支持崩溃分析工具。
- 基于UNI FUZZ平台对8种基于代码覆盖率的fuzzing技术进行了全面测试后发现，在不同测试基准下各技术的表现各有优劣。
- 通过系统评估得到了对未来fuzzing研究的重要启示，并发现某些传统未被考虑的因素对fuzzer性能的影响具有显著差异。
2 Motivation of UNI FUZZ
对模糊器进行如此全面的评估存在许多挑战，如下所示：
挑战1 ：Usability Issues of Existing Fuzzers.
现有的模糊测试工具存在 可用性问题
挑战2:Lack of Pragmatic（实用的） Real-World Benchmark Programs.
缺乏实用的现实世界基准程序。
好的基准程序应具备以下特点：
首先，在模糊测试器开发中, 我们应当选择那些具备与真实软件系统相似特点的对象, 包括编码风格、大小以及潜在漏洞. 这种做法有助于提升模糊测试器在基准测试中的相关性. 其次, 为了确保评估结果具有全面性, 所选基准系统应当涵盖多种功能类型以及不同规模. 第三, 从实际应用的角度出发, 每个基准系统都必须能够提供至少一个能够在合理时间内被发现的实际案例. 这样的话, 实用型基准体系将具备两个关键特性:(1)该系统必须至少包含一个可被发现的漏洞. 否则就无法有效区分模糊测试器在检测漏洞方面的表现.(2)发现这些漏洞所需的复杂度应在可管理范围内.
现有的模糊测试基准程序可以分为两类：合成程序和现实世界程序。
无论是合成的还是现实的，都不令人满意。
现有的合成基准通常规模较小，人为注入的漏洞是根据一些相对简单的机制设计和注入的。因此，模糊测试器的开发者可以通过了解注入模式和机制来提高其性能，评估结果可能会有偏差。因此，在这些合成基准程序上表现良好的模糊测试器可能在现实世界程序上效果不佳。
现有的真实世界基准程序存在以下问题：缺乏标准和充足的真实世界基准程序，现有的模糊器通常在自选程序上进行评估，这可能导致评估偏差；真实世界程序不如合成程序方便验证漏洞，因为缺乏明确的漏洞触发指标；现有的崩溃分类方法可能存在偏差，手动验证CVE耗时且容易出错。因此需要开发一套多样化和实用的基准程序以及自动工具来分析崩溃。
挑战3:Lack of Proper and Comprehensive Performance Metrics.
现有性能评估指标在全面度方面存在不足的问题难以得到充分验证，在模糊测试工具的实际表现中仅依赖独特的崩溃数量、独特的漏洞数量以及覆盖率等单一维度的数据往往会导致误导性的结论出现。除了单纯的漏洞数量之外（即单纯的数值大小），漏洞的质量同样是一个不容忽视的重要考量因素；此外还需要关注计算资源消耗情况等多方面的影响因素综上所述为了实现更加精准可靠的评价机制必要对评价标准进行优化升级以确保模糊测试工具能够提供更为可靠的表现数据
3 Design of UNI FUZZ
UNI FUZZ由可获取的模糊测试工具、经过验证的基准测试(benchmarks)以及准确度评估(performance metrics)这三个核心要素组成。该平台致力于解决模糊测试所面临的问题。
3.1 Usable Fuzzers
现将UNI FUZZ整合了35个功能完善的模糊测试工具，并涵盖AFL、Angora、Honggfuzz等多种主流工具。开发团队通过手动搭建并进行了全面测试，在这一过程中发现了其中一些设计与实现上的问题，并已向相关开发者提供了详细的反馈。针对每个工具我们实现了相应的Dockerfile配置文件，在这一过程中采用了Docker技术后，在资源分配与隔离方面相较于虚拟机方案更为优化。不仅验证了这些工具的基本功能与可靠性，并在此基础上进一步优化和完善了相关功能。此外，在对现有基础框架进行了充分研究的基础上，我们对八个重要的基于覆盖率的模糊测试框架进行了系统性的性能评估与分析
注：它是一种高效且便于迁移的应用程序与所需组件集成的技术。专门整合应用程序及其所有必要的组件以实现快速而可靠的效率在各种环境中运行。每个Docker容器提供一个独立且自-contained的操作环境包含应用本身以及其所需的运行为其提供的各种组件并能够在任何兼容于Docker的环境中正常运作。
3.2 Pragmatic Benchmarks
本文作者选取的真实世界基准程序包括了那些未经任何改动以保持其原有特性的程序。他们的主要关注点是如何挑选这些程序并开发工具以简化实验结果的分析过程。
3.2.2程序选择
在选择适合的程序方面，在信息安全与软件工程领域顶级会议中发表的相关论文成为关键依据。基于这一过程，在经过详细考察后我们最终确定了20个真实世界的程序实例（如表2所示）。这些程序实例涵盖了图像处理、音频处理、视频处理、文本处理、二进制数据处理以及网络数据包处理等多个功能类型，并且涉及多种潜在风险类型包括但不限于堆缓冲区溢出、栈溢出、分段错误以及内存泄漏等多种常见安全问题。
UNI FUZZ专为深入研究目标程序的行为模式和处理崩溃样本而设计。具体而言，则涵盖了以下内容：
（1）将崩溃样本去重和分类为错误；
将崩溃分为唯一的错误有两种主要方法：
一种是基于分析错误的根本原因
根本原因（错误）是指：例如崩溃文件a和崩溃文件b都触发了目标程序的错误，但在修复错误后没有触发，它们将被视为相同的错误。尽管这种方法似乎能够提供基准程序的准确真实信息，但根本原因分析很困难，并且在实践中存在许多挑战。要提供程序中所有错误的真实信息，需要访问目标程序的所有修补版本。每个修补版本应该只修复一个唯一的错误，不能重叠。否则，可能会导致大量的误报/漏报。
一种是基于分析输出结果。
例如，一种常用的方法是利用诸如ASan之类的工具，在程序出现错误时生成堆栈跟踪信息，然后使用堆栈哈希方法提取N个堆栈帧以去重错误。选择N的值可能会导致误报/漏报。然而，如何选择N的值以提供最低的误报/漏报结果是一个难题，尚未完全解决，超出了本文的范围。为了权衡和参考之前的工作[13,52]，我们选择N为3。此外，由于不同的工具使用不同的方法来检测错误，仅依赖单个工具可能会忽略某些类型的错误。因此，为了获得更精确的检测结果，我们优先考虑ASan [20]生成的输出报告，并将其他工具生成的输出报告（如GDB [21]）作为补充。
（2）将崩溃样本与相应的CVE匹配；
CVE（Common Vulnerabilities and Exposures）作为一个标准化标识系统，在信息安全领域具有公共性特点。
该系统的主要功能在于唯一识别并追踪已知信息安全管理漏洞以及公开的安全漏洞披露情况。
每个CVE标识符都包含'CVE-'前缀部分。
其中一个典型示例就是"CVE-2021-1234"。
过往的普通CVE匹配方法的缺陷：
大多数现有的模糊测试工作通过利用CVE信息来评估其模糊器发现漏洞的能力。然而,将崩溃样本与对应的CVE进行匹配是一项耗时而繁琐的过程,因为CVE描述采用自然语言编写,缺乏明确规定的结构,导致提取关键信息的过程较为困难。尽管每个CVE的参考文献可能提供额外的信息,如触发CVE所需的PoC文件以及崩溃分析工具生成的结果报告,但这些资料通常存在不完整或缺失的情况,进一步增加了匹配难度。此外,参考文献本身也是无结构化的文档,需要耗费大量时间才能确定其中链接表示的具体内容。最后,由于可能存在不同的工具用于获取输出报告,直接进行不同报告间的匹配同样面临着诸多挑战。
本文改进后的CVE匹配方法：
本文阐述了一种构建CVE关键词数据库的具体方法，并旨在便于与UNI FUZZ基准程序相关联的CVE进行匹配。该数据库为每个基准程序专门设置了CVE表，在每一个记录条目中都包含了CVE ID、漏洞类型、受其影响的函数、受其影响的文件以及堆栈跟踪等关键信息。借助该数据库系统，在初步筛选阶段即可生成一系列候选匹配结果；随后通过人工核查进一步精确定位最终符合条件的匹配结果。同时指出官方CVE网站存在一些不足之处，并且还可能隐藏着一些尚未被发现或未被报告的零日漏洞。
（3）分析由崩溃样本触发的错误的严重程度。
3.3 Performance Metrics
对现有的模糊测试论文性能指标展开全面分析，并归纳并提出了若干关键指标体系（共划分为六大类），具体包括：漏洞数量特征、漏洞质量评价、漏洞发现效率、漏洞稳定性保障、覆盖效果评估以及运行资源消耗等维度。对于每一类指标体系（共六大类），我们均提出了具体的量化评估标准与实施建议：例如，在针对"漏洞数量特征"这一维度进行定量评估时，则可采用一系列具体的数学指标（如p值计算、A12评分等）。对于每一项具体标准（共六大类），我们也都给出了相应的实践指导与应用建议：例如，在评估"漏洞数量特征"这一维度时，则可参考以下具体量化标准（如p值计算结果、A12评分平均值等）。
4.Evaluations of the State-of-the-art Fuzzers
基于UNI FUZZ平台展开了一系列实验研究
4.1 Experiment Settings
本文概述了当前在基于覆盖率的模糊测试工具中表现最佳的八种先进工具：AFL、AFLFast、Angora、Honggfuzz、MOPT、QSYM、T-Fuzz以及VUzzer64（共8种）。这些工具之所以被选中是因为它们在工业界及学术领域内具有广泛应用且采用先进技术以实现高效的测试效果。
此外，在这项研究中还采用了实际应用中的20个程序作为测试基准，并通过使用LAVA-M来评估这些工具的表现效果。
研究中详细介绍了所使用的初始种子选取标准以及实验环境的具体配置情况。
最终部分则提供了更为详尽的评估结果及相关的数据集。
4.2 Quantity of Unique Bugs
本文旨在对比多种fuzzer在识别独特漏洞方面的性能。基于ASan及GDB等工具的输出结果，在特定框架下对各类漏洞类型及其相关函数调用栈进行去重处理。通过系统化的实验评估，在UNI FUZZ基准测试集与LAVA-M平台上运行30次重复实验任务后发现：各fuzzer间的性能呈现显著差异性特征；其中QSYM以其优异的表现，在5个测试用例中取得了最优结果；而Angora则凭借其全面性优势，在多个领域展现出色；此外,Honggfuzz与MOPT均展现出较强的稳定性；值得注意的是,AFL仅在一个测试用例中表现出色
在经过30次重复实验后, 统计结果显示了七种fuzzer在四个真实世界程序上发现的独特漏洞. 基于p值和A12分数评估了fuzzer的表现, 其中AFL被用作基准进行比较. 研究结果表明, Angora、QSYM和VUzzer64分别在这所有四个LAVA-M程序上的性能均显著优于AFL. MOPT则展现了最佳的整体表现, 在其所在的17个真实世界程序中展现出最佳性能. QSYM、Angora以及Honggfuzz分别在这部分测试中取得了显著优势. 然而,AFLFast仅在一个相对较少的情况下（仅4个）显示出比AFL更好的效果, 而T-Fuzz及VUzzer64则未能在这个指标下超越AFL.
4.3 The Quality of Bugs
4.3.1 Severity of Bugs
本文阐述了如何通过多种不同的Fuzzer在多个程序中实施Fuzzing的过程。研究者采用了基于CVE-CVSS评分体系以及Exploitable数据集的方法来评估漏洞风险等级，并得出了相关结论：研究表明，在不同程序中应用不同Fuzzer时的表现存在显著差异；其中MOPT系统在检测可利用漏洞方面的性能最为突出。此外，在各个测试平台上检测到的高风险CVE数量呈现出相似性
4.3.2 Rareness of Bugs
本文对多种用于不同实际应用场景的模糊测试工具进行了性能对比分析。其中，在检测独特的罕见漏洞方面表现最为突出的是QSOM工具，在tcpdump协议上能够发现高达204个独特的罕见漏洞。紧随其后排在第二位的是MOPT工具，在多个应用程序中一共识别出90个独特的罕见漏洞。而Angora则表现更为平和，在一般应用中一共识别出56个独特但未被其他工具发现的此类缺陷。值得注意的是，在某些特定领域上这些模糊测试工具表现出明显的偏好性特征：例如，在网络流量控制协议（nm）层面上,Ancora能够识别出25个独特但未被其他工具发现的潜在问题；而在与之竞争的情况下,QSOM却未能在任何协议层面上找到相关缺陷
4.4 Speed of Finding Bugs
本文对30种不同的fuzzer进行了性能评估。根据每个fuzzer在指定时间段内所发现的独特故障案例数量进行比较，则可评估其运行效率。研究结果表明，在各个测试环境中，并非所有的fuzzer都能表现出最佳性能。值得注意的是，在不同运行阶段或环境条件下，这些fixer的表现顺序可能会发生变化。进一步地，在某些情况下، 虽然一些fixer发现了相同数量的独特故障案例, 但它们的运行效率仍存在差异. 因此, 在评估这些工具时, 速度指标的考量同样不可或缺.
4.5 Stability of Finding Bugs
本文考察了七种Fuzzer在30次重复试验中发现唯一漏洞数量的相对标准偏差（RSD）。结果表明这些Fuzzer的稳定性程度存在差异性：The Angora和T-Fuzz表现更为稳定；相比之下AFL和Honggfuzz则显得不够稳健。此外还需要指出的是这些Fuzzer的表现还与其所针对的对象程序类型相关联：The following observations highlight that the stability of these Fuzzers can vary significantly depending on the type of program they are analyzing.
4.6 Coverage
本文阐述了一种有效的方法用于追踪测试用例的覆盖情况。该方法仅选择那些能提升覆盖效果的测试用例，并致力于在精确度与效率之间取得平衡。通过对多种模糊测试工具进行比较分析，在观察到这些工具在代码覆盖率方面表现不一的同时也发现了一个重要现象：即使代码覆盖率达到较高水平，在某些情况下也可能未能显著增加独特缺陷的数量。此外研究表明这种独特缺陷数量与代码覆盖程度之间的相关性较弱
4.7 Overhead
在模糊测试过程中运行时,AFL、AFLFast和MOPT的平均内存消耗相对较低,分别为24.6 MB、22.2 MB和51.8 MB;相比之下,T-F Buzz 的 内存使用量 达到了 108
尽管存在多种模糊测试工具可供选择，在处理同一程序时它们对资源需求的表现却大相径庭。具体而言当运行exiv2这一特定程序时AFL所需的系统资源仅限于25MB左右而相比之下T-Fuzz则需要约4GB的空间以完成同样的任务。
该模糊测试工具在对不同程序进行测试时表现出显著的内存消耗差异。例如，在对pdftotext进行测试时Angora的内存占用超过了7 GB而在对其他程序进行测试其内存占用低于2 GB
5 Further Analysis
评估了未被充分考虑的关键因素（如仪器化方法及其相关技术），并结合崩溃分析工具等技术手段进行深入考察。这些关键因素对其性能具有显著影响
5.1 Instrumentation Methods（仪器化方法）
采用不同仪器方法的模糊测试工具之间存在显著差异性
选择不同的编译策略将直接影响漏洞的触发情况。然而，在实际应用中我们发现即使采用相同的开发环境也可能得到完全不同的结果出现。为了深入研究这个问题建议采用交叉验证的方法来分析这些崩溃样本的具体表现也就是说在对这些程序进行重新编译后再次运行相同的崩溃测试以便确定这些程序在经过重新编译后是否仅能引发部分程序崩溃的问题？
5.2 Crash Analysis Tools
采用多种分析工具对崩溃样本进行处理可能会产生不同的结果。在对收集的329,857个崩溃样本进行分析时，其中约61.1%的样本同时被ASan和GDB验证；约14.5%的样本仅能通过GDB进行验证；约12.2%的样本仅能被ASan确认；而剩余约12.2%则无法被任何工具所识别。这些数据表明，在当前环境下使用较为流行的ASan工具能够确认约73.3%的有效崩溃事件。
单一分析工具的应用可能导致可探测漏洞的数量有限；因此为了更有效地进行崩溃样本分析需综合运用多种静态解析框架；从而更加深入地了解模糊测试器的特性；在对ffmpeg执行静态分析时发现通过不同静态分析框架的运行结果发现；当比较多个解析框架的表现特征时会发现其存在显著差异；鉴于此在静态代码检查过程中优先选择ASan框架进行缺陷定位并配合GDB框架辅助定位潜在问题