近年来，大型语言模型（llm）的编程能力引起了极大的关注。模糊测试是一种高效的技术，在提高软件可靠性和检测漏洞方面起着关键作用。然而，传统的模糊测试工具依赖于手工制作的模糊驱动程序，这可能会限制测试的效率和有效性。为了应对这一挑战，我们提出了一种自动化模糊测试方法，该方法由代码知识图驱动，并由基于llm的智能代理系统（称为CKGFuzzer）提供支持。我们将模糊驱动程序创建作为代码生成任务，利用代码存储库的知识图在模糊循环中自动化生成过程，同时不断地细化模糊驱动程序和输入种子。通过程序间分析构建代码知识图，图中的每个节点代表一个代码实体，如函数或文件。知识图增强的CKGFuzzer不仅可以有效解决模糊驱动中的编译错误，生成针对特定API使用场景的输入种子，还可以分析模糊驱动崩溃报告，帮助开发人员提高代码质量。通过查询代码库的知识图和从API使用场景中学习，我们可以更好地识别测试目标，并了解每个模糊驱动程序的特定目的。我们使用八个开源软件项目来评估我们的方法。实验结果表明，与最先进的技术相比，CKGFuzzer在代码覆盖率方面平均提高了8.73%。此外，CKGFuzzer将崩溃案例分析中的人工审查工作量减少了84.4%，并在测试库中成功检测到11个真正的bug（包括9个以前未报告的bug）。我们的研究通过改进模糊驱动生成策略和输入种子分析，提高了模糊测试的整体性能，为漏洞修复和软件质量改进提供了更有效的解决方案。

本文的研究动机主要有两点：

1.现有的基于大模型的库模糊测试驱动生成工具大多是zero-shot 的，本文借鉴RAG 思想，为模糊测试驱动的生成从目标库中提取相关的context，以辅助和增强大模型生成有效测试驱动的能力

2.使用大模型生成的模糊测试驱动缺少对应的种子，本文利用大模型来为模糊测试驱动生成对应的种子。

3.使用生成的驱动进行Fuzz 得到的Crash 可能来自API 的误用，也可能是真实的bug。针对Crash 的分析费时费力。本文利用大模型实现Crash 的自动化分析。

图 1 CKGFuzze 工作流

最初，CKGFuzzer解析得到目标库中的api，从被测项目中提取代码的知识图谱并生成其嵌入。这个解析过程包括两个步骤：首先，解析抽象语法树，其次，执行过程间程序分析。解析器提取关键信息，如数据结构、函数实现、函数签名和调用关系。

接下来，CKGFuzzer对于库中的每个API，基于调用关系或功能相似性，获取API组合并生成相应的模糊驱动程序。CKGFuzzer然后尝试编译这些生成的模糊驱动程序并解决出现的编译错误。

在驱动程序生成和修复过程中，我们为CKGFuzzer提供了一个动态更新的库使用知识库。一旦成功编译了fuzz驱动程序，CKGFuzzer就会执行它们，同时监视每个库文件的代码覆盖率。它采用代码覆盖引导的迭代过程来改变无法覆盖新路径的API组合。这个迭代过程会一直持续下去，直到发现新的代码路径或耗尽突变预算为止。

最后，CKGFuzzer使用思维链推理来分析在模糊测试期间产生的任何崩溃。为了验证这些崩溃的有效性，我们引用了一个llm生成的知识库，其中包含与cwe相关的真实源代码示例。

1．目标库代码知识图谱的创建 

CKGFuzzer 中的代码知识图谱由三种节点组成：

1)文件节点D

2)函数节点F

3)外部函数LIBRARY FUNCTION

其中的边有两种

1)D -> F 的 包含 关系

2)F -> F 的call 关系。特别地，CKG会为外部函数创建 LIBARRY FUNCTION 节点 和 LIBRARY CALL 的边

其中，F 节点包含 源代码、签名、摘要（summary） 等属性。D 节点包含 摘要（summary） 属性。

2．API 组合的生成 

（API Combination Generation）

图 2 API 组合生成算法

算法如上图所示。借助嵌入生成和相似度匹配的方法，根据 query 搜寻相关的 chunks 。根据 Chunks 迭代地优化 query 的答案 repsponse 。 最后从 response 提取出相关的 API 组合。

3．模糊测试驱动生成 

（Fuzz Driver Generation）

本文通过构建提示词，指导大模型进行模糊测试驱动的生成。我们的提示词策略强调模糊驱动程序生成的几个关键方面：

1)任务定义：LLM的任务是生成一个模糊驱动程序来测试提供的API组合。提示符指定每个API必须在函数LLVMFuzzerTestOneInput中调用，以确保API集的全面测试覆盖率。

2)API上下文：提示符包括API源代码、头和自然语言摘要。这为LLM提供了必要的上下文，以正确利用api并根据其功能和约束管理其输入和输出。

3)错误处理：为了防止模糊驱动程序本身不稳定，这可能导致崩溃并降低整体模糊效率，提示符包括明确的指令，用于稳健的错误处理和仔细的内存管理。

4．动态程序修复

（Dynamic Program Repair）

图3 模糊测试驱动修复

算法如上图所示。为了实现动态程序修复，我们首先初始化一个知识库，其中包含正确的库API用法，该知识库由来自OSS-Fuzz的fuzz驱动程序示例和库的头文件构建。值得注意的是，虽然OSSFuzz代码侧重于单个API，但我们的方法处理API组合。头文件有助于解决由于缺少include语句而导致的错误。当CKGFuzzer遇到编译失败时，它处理编译器错误消息并构造一个查询来搜索外部知识库，以查找错误API或代码片段的正确用法。CKGFuzzer继续查询知识库并迭代地应用修复，直到fuzz驱动程序成功编译或达到最大迭代限制。

此外，所有成功编译的模糊驱动程序都被插入到知识库中，动态更新正确API使用模式的存储库。这种动态更新策略确保知识库随着时间的推移而发展，逐渐扩展到涵盖跨不同库的更广泛的API使用场景。因此，我们的方法在修复错误方面保持了高水平的适应性和准确性，减少了反复编译失败的机会。

5．输入种子池的初始化 

（Input Bank Initialization）

在模糊测试开始之前，我们通过使用llm为每个模糊驱动程序生成输入种子来初始化输入库。输入生成过程从对模糊驱动程序的数据流的详细分析开始，在这里我们提取变量之间的价值流关系。随后，我们提取与模糊驱动程序交互的API函数签名，这有助于理解预期输入的结构和约束。

6．覆盖率引导的变异

（Coverage Guided Mutationr）

图4 覆盖率引导的变异

在模糊测试过程中，CKGFuzzer监视每个模糊驱动程序实现的代码覆盖率。它分析整个库的覆盖率数据，并识别与整个库相比覆盖率较低的文件。对于每个低覆盖率文件，将提取定义的API函数，并根据文件的覆盖率排名生成一个优先级列表，称为低覆盖率API列表。

然后，这个低覆盖率API列表用于指导LLM在模糊驱动程序中突变和重组当前API组合。其目标是通过关注未开发的api来探索新的执行路径并增加代码覆盖率。如算法3所示，突变过程是迭代的：CKGFuzzer根据低覆盖率API列表继续查询具有新API组合的LLM，直到覆盖新的分支或计算资源耗尽。

7. 崩溃分析

（Crash Analysis）

1．CKGFuzzer相比其他Fuzzer 的有效性 

图 5 覆盖率评估

我们选取了八个开源库进行评估：c-ares、cjson、curl、lcms、libpcap、libtiff、libvpx 和 zlib。这些库因其 API 使用的多样性以及在各类软件项目中的广泛应用而被选中。我们将 CKGFuzzer 与其他开源模糊测试器进行了比较，重点对比了基于覆盖率引导的模糊测试器（OSS-Fuzz）和基于大语言模型的模糊测试器（PromptFuzz）。

在评估过程中，我们在每个库上运行来自OSS-Fuzz 的模糊测试驱动程序，持续 24 小时。所使用的生成模型为DeepSeek-V2-Coder。如果某个库在 OSS-Fuzz 中包含多个模糊测试驱动，我们会为每个驱动分配相同的时间预算，以确保总模糊测试时间为 24 小时。对于 PromptFuzz，我们使用了与 CKGFuzzer 相同的 API 列表，并将模糊测试的时间也控制为 24 小时。

随后，我们根据代码覆盖率对CKGFuzzer 的有效性进行了评估。CKGFuzzer、PromptFuzz 和 OSS-Fuzz 的代码覆盖率结果如图5所示。在与其他模糊测试器的对比中，CKGFuzzer 在所测试的 8 个库中，有 6 个取得了最高的分支覆盖率。这种优越性在很大程度上归功于 CKGFuzzer 所生成的结构化 API 组合，这些组合来自一个全面的代码知识图谱，使得 CKGFuzzer 能够捕捉 API 之间复杂的关系与语义依赖，从而生成更具意义的模糊测试驱动程序。

2．每种智能体对CKGFUzzer 有效性的贡献

图 6 消融实验表

我们评估的组件包括API组合生成、编译修复和API组合突变的代码知识图谱。

1)代码知识图：为了评估代码知识图对CKGFuzzer生成的模糊驱动质量的影响，我们将其与使用库中基于文本的API知识的变体进行了比较。这种变体通过查询由API源代码和API摘要组成的基于文本的知识库来生成API组合。图6的实验结果表明，纯文本检索变体比CKGFuzzer实现了更低的代码覆盖率，这突出了代码知识图在生成高质量模糊驱动方面的有效性。

2)编译修复：在CKGFuzzer中，我们引入了动态程序修复组件来修复遇到编译错误的fuzzer驱动程序。在本节中，我们设计实验来评估CKGFuzzer修复编译错误的有效性以及动态程序修复组件对模糊性能的影响。首先，我们创建了两个变体：一个没有任何编译错误修复（没有修复），另一个仅依赖LLM进行程序修复（仅LLM修复）。表2的实验结果显示，未修复的平均编译成功率仅为57.39%(458/798)，说明CKGFuzzer很难直接生成可编译的模糊驱动程序。另一方面，仅llm修复将编译成功率提高到77.19%(616/798)，显示了llm在程序修复方面的巨大潜力。然而，CKGFuzzer的编译成功率为93.99%(750/798)，突出了动态程序修复组件在修复模糊驱动程序编译错误方面的有效性。

图 7 覆盖率引导消融实验

此外，我们还评估了两个变体的代码覆盖率表现。表II 的结果显示，无修复版本和仅使用大语言模型修复的版本在代码覆盖率方面均低于 CKGFuzzer。这是因为许多模糊测试驱动程序包含独特的 API 组合，但无法成功编译，因此无法参与模糊测试过程，限制了通过多样化的 API 组合在库中探索新的执行路径的潜力。

3)基于覆盖率的变异机制：CKGFuzzer 利用基于覆盖率引导的变异机制来发现潜在的新 API 组合。为了评估其有效性，我们与一个不进行 API 组合变异的变体进行了对比实验。我们将两个方法的模糊测试时间都固定为 24 小时，以比较它们的覆盖率变化趋势。图 2 展示了 CKGFuzzer 在启用和不启用 API 组合变异的情况下，在不同库中获得的分支覆盖率结果。

3．崩溃分析的效果

图 8 崩溃分析

CKGFuzzer 在模糊测试过程中共发现了 199 个独特的崩溃，其中有 168 个被崩溃分析模块判定为由库 API 的误用引起。为了尽量减少误报，崩溃分析模块会将那些难以明确分类或存在歧义的情况也视为 API 误用导致的崩溃。例如，如果某次崩溃是由于向库 API 传递了不存在或错误的指针，而该 API 本身没有使用防御性编程来验证输入指针的有效性，我们仍将此类情况归类为误用崩溃。

为了验证崩溃分析模块在识别API 误用崩溃方面的准确性，我们从每个库的误用崩溃案例中随机抽取了 10% 进行人工检查。经过审查，我们确认这些崩溃确实都是由于模糊测试驱动程序错误使用 API 所导致的。

1.不同编程语言的适用性

CKGFuzzer 主要是在基于 C 的库上进行评估的，这些库广泛使用，且其 API 文档完善。然而，CKGFuzzer 在其他编程语言（如 Rust、Java 或 Python）中的适用性仍是一个尚未解决的问题。由于每种语言的 API 设计存在差异，CKGFuzzer 可能需要进行相应的调整才能有效应对这些差异。未来的研究可以探索将 CKGFuzzer 适配到这些语言中，从而拓展其应用范围和实用性。

2.代码知识图谱的质量

代码知识图谱在 CKGFuzzer 中起着核心作用，它指导 API 组合的生成，并在基于覆盖率的变异过程中更新 API 组合。代码知识图谱的完整性和准确性对于生成有效的模糊测试驱动程序至关重要。在我们的实验中，拥有更全面代码知识图谱的库表现出更好的覆盖率和更高的模糊测试效率。提升代码知识图谱的自动化构建与验证能力，有助于进一步提升 CKGFuzzer 的性能，确保其准确反映库的 API 结构和使用模式。

在本文中，我们提出了CKGFuzzer，一个新的由代码知识图增强的llm驱动的模糊测试框架。CKGFuzzer自动生成模糊驱动程序，并引入了几个关键特性来提高模糊测试的有效性。其中包括一个覆盖引导的突变策略，它迭代地改进API组合以探索新的执行路径，一个动态程序修复机制，它自动解决生成的模糊驱动程序中的编译错误，以及一个崩溃分析模块，它有助于识别运行时失败的根本原因。我们在8个开源项目上的实验表明，CKGFuzzer实现了更好的代码覆盖率，并成功检测了11个真实世界的bug。覆盖引导的突变可以更广泛地探索代码路径，而动态程序修复和崩溃分析模块显著减少了人工干预，使模糊测试过程更加高效和可靠。这些结果突出了利用llm和代码知识图来推进自动化模糊测试的潜力。 

ECFuzz：面向大规模系统配置项设置的高效模糊测试 

WhiteFox：由大型语言模型驱动的白盒编译器模糊测试 

BAZZAFL：通过面向漏洞的种子分组将模糊测试活动导向漏洞

阅读原文

跳转微信打开

配置在模糊测试中是另一个程序输入，它像输入数据一样直接控制程序行为。大规模系统因其海量配置参数导致配置空间庞大，且大多数配置参数具有灵活的约束，因此，在探索配置输入空间时，会导致配置参数间的组合爆炸问题。现有的测试方法在处理复杂配置时存在显著局限性。首先，多数方法独立生成单个配置参数，忽视参数间依赖关系，导致无效测试和代码覆盖率低。其次，直接依赖耗时系统测试验证配置，未利用单元测试预筛选，浪费资源。

针对上述问题，作者提出ECFuzz，一种基于多维度配置生成与单元测试导向验证的模糊测试框架。其核心贡献在于：

（1）多维度配置生成策略：通过分析配置参数间的控制、数值、默认值及行为依赖关系，设计差异化变异规则，动态调整参数组合规模，有效覆盖深层交互场景；

（2）单元测试驱动的验证机制：利用配置参数与单元测试的映射关系，优先执行轻量级单元测试筛选潜在错误配置，显著降低高开销系统测试的无效执行。

实验表明，ECFuzz在HCommon、HDFS等5个主流大规模系统中注入1000个测试用例时，意外故障发现数量较ConfTest等工具提升1.87-2.63倍，平均测试用例质量达92.5‰，并成功检测出14个未知配置错误（5个已确认）。

为了提高配置测试的有效性，关键是选择一小部分有代表性的配置参数作为测试用例。要实现这一目标需要考虑两个因素：

1）配置参数生成：生成高质量的配置参数作为测试用例，避免在PUT启动阶段被提前过滤掉，在程序运行阶段探索更多的代码。

2）配置参数验证：有效的测试用例验证方法可以快速验证生成的测试用例是否有助于发现错误，并避免在不太可能产生错误的测试用例上浪费大量时间在系统测试期间。

然而，现有的配置测试技术没有充分考虑大规模系统的复杂性，导致测试有效性低。有以下两个挑战：

挑战：

(1) 如何有效生成配置参数。现有的工作一些使用基于字典或基于语法的模糊技术来生成满足语法有效性的配置参数;另一些使用基于约束的模糊技术来生成违反配置约束的配置参数。多数方法每次仅针对单一参数生成测试用例，忽略参数间存在依赖关系，生成大量无效配置。

(2)如何有效验证生成的配置参数。现有的配置测试技术往往直接将生成的配置参数注入到PUT中进行系统测试，然后监控PUT的状态，验证配置参数是否会触发bug。在小规模程序中，由于系统测试的执行速度快，该方法的时间开销是可以接受的。然而，在大型系统中，执行系统测试的时间成本非常高。一旦生成了不太可能产生错误的配置参数，通常需要花费大量时间对其进行系统测试，资源浪费严重。

针对上述的问题，作者设计了ECFuzz：

(1)多维配置生成策略。为了有效地生成大规模系统中的配置参数，提出一种多维配置生成策略。ECFuzz通过分析配置参数间的依赖关系，设计智能变异策略；动态选择多参数组合进行协同变异，并根据测试反馈智能调整参数规模，突破传统单参数变异的局限性。

(2)单元测试导向的配置验证策略。ECFuzz利用大规模系统完备的单元测试特性，构建配置参数与单元测试的映射关系，通过轻量级单元测试实现高效配置筛选。

图 1  ECFuzz的完整流程图

ECFuzz的完整架构如图1所示，主要包括两个关键部分：

(1)配置参数生成：ECFuzz将默认配置文件和依赖表作为初始输入，然后生成新的配置参数作为测试用例。配置参数生成包括种子生成和智能变异两部分，ECFuzz首先使用种子生成来选择在该模糊化活动中需要进行模糊化的配置参数作为种子，然后使用智能变异来变异这些配置参数以获得测试用例。

(2)配置参数验证：生成测试用例后，ECFuzz通过配置参数与单元测试的映射关系自动获取对应的单元测试，并实时监控它们的运行结果。一旦失败发生，ECFuzz终止单元测试并将单元测试的结果设置为失败。如果单元测试完成且未发生失败，则单元测试的结果设置为成功。

1．配置参数生成

（Generate configuration parameters）

(1)种子生成：在配置模糊中，种子是一组配置参数。它指示在模糊攻击中哪些配置参数值得花费精力进行变异，我们从默认配置文件中随机选择几个配置参数，然后根据依赖关系表查找相关配置参数，如算法1所示。

依赖关系表：描述了cDEP2分析的依赖关系表中的依赖关系类型。这里以元组列表的形式描述依赖关系表本身。

Type：依赖类型（由工具cDEP2分析得出）。

ConfA和ConfB：存在依赖关系的两个配置参数。

随机选择：随机选择策略从默认配置文件中随机选择K个配置参数。

相关配置参数搜索：为了保证种子的质量，需要在选择配置参数后，根据种子的依赖关系，添加相应的依赖配置参数。ECFuzz遍历随机选择的配置参数数组。如果在依赖关系表中找到了相关的配置参数，并且这是它第一次出现在中，则配置参数将被添加到。最后，选择上述配置参数组来构造一个新的种子。

(2)智能变异。智能变异算法充分考虑了种子中配置参数对应的依赖关系和约束条件，具体算法如算法2所示。

在智能变异期间，ECFuzz首先初始化测试用例。然后，根据变异的数量开始智能突变。在每次变异开始之前，随机选择其中一个配置参数的索引作为变异对象。随后，ECFuzz确定配置参数是否具有相应的依赖关系。如果存在，则通过根据依赖关系的变异来获得newValue。否则，通过根据约束的变异来获得newValue。最后，newValue覆盖对应于测试用例的初始值。

根据依赖关系生成新的配置参数值:ECFuzz使用cDEP分析的依赖关系表（如图2所示）。cDEP支持控制依赖、值关系依赖、重写依赖、默认值依赖和行为依赖5种依赖。但覆盖依赖在表中只出现了3次，因此ECFuzz没有考虑覆盖依赖。根据不同依赖关系的特点，设计了相应的变异方法。

控制依赖：第二个参数仅在第一个参数为True时生效。

变异方法：在依赖关系表中，没有告诉我们哪一个是控制参数。因此，ECFuzz通过判断其类型是否为布尔类型来确定。如果配置参数都为非布尔类型则跳过这条依赖记录。如果是布尔类型且当前变异的配置参数是主控参数，ECFuzz会根据其约束条件进行变异；若是被控参数，ECFuzz会先将主控参数的值设置为True，然后根据其约束条件对被控参数进行变异。

值关系依赖：一个参数的值受到另一个参数的值约束。一般分为三种类型：数值约束，参数A的值必须大于参数B的值（A > B）；逻辑约束，参数A为true时，参数B必须为特定取值范围；集合约束，参数A的值必须是参数B值的子集。

变异方法：根据约束条件同时改变两个变量的值。

默认值依赖：如果第一个参数的值不可用，则将第二个参数的值用作其默认值。

变异方法：根据其中一个配置参数的约束条件对其进行变异，然后将另一个配置参数设置为相同的值。

行为依赖：第一个参数与第二个参数一起作用于系统的某些行为。

变异方法：根据两个参数各自的约束条件对其进行变异。

对于智能变异，突变的数量显著影响其性能。N如果很小，则很难发现由多个配置参数引起的bug。在特殊情况下，如变异系数为1，智能变异算法退化为单变异算法。如果突变数很大，将大大增加突变的时间成本和难度。

解决方法：智能变异策略的动态切换。

单次变异优先（N=1），快速生成大量简单测试用例，覆盖常见错误。一段时间内未发现新的异常时，认为简单变异已无法触发深层错误。切换至堆叠变异（N=3~6），通过同时变异多个参数，生成更复杂的组合，暴露参数间交互引发的隐藏问题。

2．配置参数验证

（Configuration Validation）

在配置验证中，ECFuzz为被测程序（PUT）构建运行环境，包括单元测试阶段和系统测试阶段，具体算法如算法3所示。

单元测试阶段：单元测试阶段通过搜索和执行与测试用例相关联的单元测试来快速测试测试用例的bug触发潜力。

单元测试阶段包括以下三个部分：

单元测试搜索：ECFuzz根据ctest 的映射关系，从PUT提供的大量单元测试中，找出测试用例中只与配置参数相关的部分作为候选单元测试集。

单元测试缩减：当测试用例中包含大量配置参数时，单元测试搜索会生成规模庞大的候选测试集，其执行耗时很长。因此，ECFuzz使用采样和时间过滤算法来压缩候选单元测试集的大小。抽样算法是从候选单元测试集中按一定比例抽取一部分来替换原始集合。时间过滤算法检测每个单元测试的执行时间，并根据先验知识过滤掉耗时过长的单元测试。

单元测试执行：在得到候选单元测试的约简集后，ECFuzz构造出执行单元测试所需的运行环境。只有当测试用例通过所有单元测试时，单元测试阶段的结果才是成功的。ECFuzz不需要每次都运行所有的单元测试。一旦测试用例在单元测试中失败，则单元测试阶段被终止，并且单元测试结果被设置为失败。此外，不管单元测试是否通过，单元测试阶段的结果都返回到系统测试阶段，但是仅当单元测试失败时，才保存测试用例以供稍后分析。

系统测试阶段：运行单元测试后，ECFuzz进入系统测试阶段，进一步测试测试用例是否能在真实的系统环境中触发bug。

系统测试阶段包括以下三个部分：

系统环境搭建：ECFuzz根据PUT的类型构造相应的系统编译环境、运行环境和测试输入。

配置文件替换：在开始系统测试之前，ECFuzz将测试用例中的配置参数信息转换为一个完整的符合大规模系统的输入要求配置文件。新配置文件用于替换默认配置文件，作为PUT的新输入。

系统测试执行与监控：ECFuzz创建进程来启动系统测试，并持续监视测试执行的状态。在系统测试阶段，ECFuzz会针对程序运行的三个关键环节进行异常监控：启动阶段、运行阶段以及关闭阶段。启动异常，程序前期不能完全启动；运行时异常，程序崩溃、挂起；关闭异常：程序无法正常关闭。如果系统在注入一些配置参数后出现启动异常，这是正常的反应，因为这意味着系统可以在配置上线生产之前立即检查这些配置参数。因此，将运行时异常和关闭异常视为意外故障。一旦测试用例触发了意外故障，我们就认为已经发现了潜在的错误，并将其记录下来以供后续的再现和分析。

RQ1：ECFuzz的多维配置生成策略与单次变异相比如何？

RQ2：ECFuzz的面向单元测试的配置验证策略在提高测试用例质量方面有多大的效果？

RQ3：与最先进的配置测试技术相比，ECFuzz的测试用例和异常类型的质量如何？

RQ4：与最先进的配置测试技术相比，ECFuzz在暴露未知错误方面的效率如何？

1．实验设置 

表 1 测试目标

环境：实验在KVM虚拟机上运行，配置为4核CPU、4GB内存，操作系统为Ubuntu 16.04 LTS。每个实验运行12小时，重复5次以确保结果统计意义。

测试目标：选取5个广泛使用的大型系统：HCommon、HDFS、HBase、ZooKeeper和Alluxio，覆盖分布式存储、数据库和协调服务等场景。

监控策略：

内部监控：监视被测输入的PUT的内部状态。如果在PUT中发现异常（启动异常、运行时异常和关闭异常）则由内部监视器抛出异常。

外部监控：获取从内部监视器抛出的异常，并进行分析计算。此外，在系统测试期间，它会监视内存、CPU以及日志。如果异常是运行时异常或关闭异常，外部监视器将其视为意外故障。

2．多维配置生成策略评估（RQ1）

表 2 不同配置测试工具的测试用例质量

表 3 多维配置生成策略评估的异常类型

单变异是指在每个模糊活动期间仅从候选配置参数中选择单个配置参数而不考虑依赖性。我们将这种单突变策略称为ECFuzz-S。表2和表3分别显示了不同策略的测试用例质量和异常类型的结果。

ECFuzzz测试用例的质量比ECFuzz-S有了显著的提高。ECFuzz-S和ECFuzz的测试用例总质量分别为20.6‰和92.5‰。这意味着，当相同的1000个测试用例被注入到系统中时，ECFuzz会多发现71.9个意外失败。对于异常类型，ECFuzz可以找到ECFuzz-S在所有五个程序中都找不到的多个唯一异常。总体而言，ECFuzz比ECFuzz-S多发现了9种异常类型，增加了128.6%。

ECFuzz之所以能取得上述好的结果，有两个原因：1）ECFuzz充分考虑了大规模系统中的配置依赖关系，并为每种依赖关系设计了相应的变异策略，提高了发现意外故障的能力; 2）ECFuzz在每次模糊化活动中从候选配置参数中选择多个配置参数，并根据测试结果进行智能调整，因此ECFuzz可以在同一次模糊化过程中探索更多的程序代码。

3．单元测试导向的的配置验证策略评估（RQ2）

表 4 不同配置测试工具的测试用例质量

为了有效地验证生成的配置参数，ECFuzz设计了一个面向单元测试的配置验证策略。为了证明其有效性，我们将其与直接注入系统测试而不使用单元测试的策略进行了比较。我们将此策略称为ECFuzz-W。表4显示了不同策略的测试用例的质量结果。

我们发现ECFuzz-W和ECFuzz的测试用例的总质量分别为38.4‰和92.5‰。这意味着，当相同的1000个测试用例被注入到系统中时，ECFuzz会多发现54.1个意外失败。ECFuzz-W直接将生成的测试用例注入到PUT中执行系统测试，生成更多的测试用例。然而，大多数测试用例都被PUT的配置解析代码过滤，导致启动异常。与ECFuzz-W相比，ECFuzz使用单元测试导向的配置验证策略，在执行系统测试之前提前过滤掉不太可能产生错误的测试用例，减少了昂贵的系统测试开销。因此，ECFuzz可以显著提高测试用例的质量。

为了展示ECFuzz的有效性，我们将其与三种最先进的配置测试工具进行了比较，ConfTest，ConfErr和ConfDiagDetector。表5显示了不同工具的测试用例质量，图2显示了异常类型的结果。

表 5 不同配置测试工具的测试用例质量

图 3 异常类型图

本文提出了一种针对大规模系统的高效配置模糊测试工具ECFuzz，通过多维度配置生成策略和单元测试导向的验证策略，显著提升了测试效率。实验表明，ECFuzz在Hadoop、HBase等系统中意外失败率较现有工具提升1.87-2.63倍，发现14个未知配置错误（5个已确认），有效解决了传统方法因忽略参数依赖和系统测试耗时导致的效率低下问题，为大规模系统配置测试提供了创新性解决方案。

WhiteFox：由大型语言模型驱动的白盒编译器模糊测试

BAZZAFL：通过面向漏洞的种子分组将模糊测试活动导向漏洞

通过命令行反馈利用大语言模型提高编译器选项黑盒模糊测试

阅读原文

跳转微信打开

现代编译器在将高级编程语言翻译为高效机器代码的过程中扮演着至关重要的角色。然而，不正确或错误应用的优化可能导致难以察觉的漏洞，甚至引发安全问题。在现有文献中，模糊测试已被广泛研究以揭示编译器缺陷。然而，编译器模糊测试仍然面临挑战：现有技术主要集中在黑盒和灰盒模糊测试上，这些方法在生成测试程序时对编译器内部行为缺乏充分理解。因此，它们往往难以构建能够测试复杂优化过程的测试程序。同时，传统的白盒技术，如符号执行，由于计算资源限制，难以适用于庞大的编译器系统代码库。

由于大型语言模型（LLMs）在代码生成和理解任务中表现出色，甚至在黑盒模糊测试中达到了最先进的性能，论文提出了首个利用大型语言模型结合源代码信息的白盒编译器模糊测试工具WhiteFox，专注于检测新兴深度学习（DL）编译器中的深层逻辑错误。WhiteFox采用多智能体框架：

（1）基于LLM的分析智能体：检查低级优化源代码，并生成能够触发优化过程的高级测试程序的需求；

（2）基于LLM的生成智能体：根据总结的需求生成测试程序；

（3）反馈循环：触发优化的测试程序会作为反馈的少样本示例，动态增强测试生成的提示信息。

挑战：

（1）黑盒模糊测试：由于缺乏对内部工作原理的了解，在触发优化所需的复杂条件方面面临困难。

（2）灰盒模糊测试：虽借助源码插桩实现更高覆盖率，但其对编译器优化条件的敏感度仍然不足，因为优化往往依赖严格精确的条件，而传统覆盖率驱动策略难以有效捕捉这些微妙状态。此外，现有方法因生成输入缺乏语义正确性，主要暴露前端崩溃错误，而非深层优化缺陷。

（3）传统的白盒模糊测试：依赖于对SUT 源代码的严格分析，但在现代编译器上变得难以实施。

（4）通用性较差：现有编译器测试工具多针对特定语言或编译器定制，开发新编译器的测试框架耗时费力，难以复用。

例子：图1展示了PyTorch Inductor中优化permute_linear_fusion的一个示例。该优化在对输入张量调用permute方法时，将permute和linear操作符融合，特别是交换最后两个维度。然而，当应用模糊测试技术来测试此优化时，黑盒/灰盒模糊测试难以生成符合这些约束的模型。这是因为黑盒和灰盒模糊测试工具由于缺乏源代码实现的指导，无法意识到模型应以这种特定方式包含permute和linear操作符。另一方面，尽管白盒技术在理论上有可能触发此优化，但由于编译器中数据结构的复杂性（例如torch.fx.GraphModule和torch.fx.Node），应用传统的程序分析从详细的源代码中提取约束是不现实的。

图 1  动机示例

针对上述问题，作者设计了WhiteFox：

（1）由于现有的白盒测试方法无法扩展到对复杂编译器系统的行为信息进行建模，WhiteFox 的核心思想是利用 LLMs 自动推断能够触发编译器优化的测试程序需求，这些需求基于优化模块的源代码实现。

（2）WhiteFox 的输入是实现编译器优化的源代码，首先由基于 LLM 的分析代理自动分析并总结触发优化的测试需求，随后基于 LLM 的生成代理根据生成的需求生成大量有意义的测试程序。

（3）为了生成能够直接执行相应优化的测试程序，WhiteFox 进一步采用了反馈循环机制，将触发优化的测试作为少样本示例，以指导未来的测试生成。

（4）除了 DL 编译器测试，WhiteFox 还可以适配其他编译器甚至复杂的现实世界软件系统的白盒模糊测试，为这一有前景的方向启发了未来的研究。论文已将 WhiteFox 适配用于测试 LLVM 并发现了多个错误。

图 2  WhiteFox的完整流程

WhiteFox的架构如图2所示，主要包括三个关键部分：

（1）需求总结：分析型LLM 通过检查编译器优化的源代码，提取触发优化所需的测试需求。

（2）测试生成：生成型LLM 根据提取的需求，自动生成用于触发优化的测试程序。

（3）反馈循环：生成的测试程序随后被编译和执行，通过插桩观察优化是否被触发，并将成功触发优化的测试纳入反馈机制，作为示例指导生成型LLM 在后续迭代中生成更具优化针对性的测试程序。

此外，为了检测编译器错误，每个测试程序都会通过测试预言（如结果不一致、编译时崩溃和运行时崩溃）进行验证。

值得注意的是，WhiteFox 采用了多智能体框架，这种设计能够平衡不同 LLMs 提供的成本和收益之间的权衡。例如，可以让分析 LLM 具备广泛的知识和推理能力（在自然语言和代码方面），而让生成 LLM 专门用于高效的程序生成。

1. 需求总结  

（Requirement Summarization）

挑战：（1）代码冗长且包含无关信息：优化代码往往包含大量实现细节（如数据结构操作、错误日志记录），增加了LLM 理解的难度。（2）低级实现，涉及复杂数据结构：实现代码是低级别的，涉及大量的领域特定模块、IR 和辅助函数。

解决方案：采用了一种混合格式，将自然语言和伪代码结合起来描述触发优化的需求，而不是仅仅依赖其中一种格式。

（1）自然语言（NL）：清晰概括优化触发条件，去除不必要的细节。例如，PyTorch Inductor 中的 `permute_linear_fusion` 优化要求 “它交换了张量的最后两个维度”，利用伪代码清晰简洁地描述这一点相当具有挑战性，自然语言描述更加适合。

（2）伪代码（Pseudo-Code）：用于表达关键代码模式，使测试生成更直观。例如，PyTorch Inductor 中的 `permute_linear_fusion` 优化要求”首先调用张量方法 `permute`，然后在置换后的张量上调用 `torch.nn.functional.linear` 函数”。对于这种情况，自然语言描述不如伪代码格式直观，”张量方法 `permute`”可以用伪代码简单地表示为 `input_tensor.permute(...)`。

具体实现：WhiteFox使用少样本上下文学习来提示分析型LLM 以自然语言和伪代码的混合格式生成其触发需求。

（1）图 3(a) 展示了用于总结目标编译器中优化需求的通用少样本提示模板。该提示模板以指令”请描述可以触发 [OPTIMIZATION NAME] 优化的 [TARGET INPUT]...”开头，其中 [TARGET INPUT] 是目标编译器特定的输入格式。然后，它后面跟着优化实现的源代码，并以输入应满足的需求描述结束。描述是自然语言和伪代码的混合格式，由 [PSEUDO CODE] 和 [NL DESCRIPTION] 组成。Target Optimization与少样本示例具有相同的结构，但其需求字段留空，等待LLM 生成。

（2）图 3(b) 展示了PyTorch Inductor 中的需求总结少样本提示。PyTorch Inductor 的预期输入格式是 PyTorch 模型；因此，[TARGET INPUT] 填充为”PyTorch 模型”。随后，提供了示例优化 `permute_linear_fusion` 的源代码。最后，以伪代码和自然语言混合格式给出示例描述，以概述触发示例优化所需的约束条件。

图3 WhiteFox的需求总结提示模板

2. 测试生成 

（Test Generation）

通过利用优化的需求描述，WhiteFox 利用 LLM 的能力生成能够有效触发相应优化以进行错误检测的测试输入。与需求总结类似，论文利用少样本上下文学习来生成基于需求的特定于每个优化的测试输入。

（1）图 4(a) 展示了 WhiteFox 中用于测试生成的通用提示模板。少样本示例的结构包括一条指令，具体为：”请生成一个有效的 [TARGET INPUT] 示例，该示例具有 [INPUT SPECIFICATION] 并满足指定的需求。”然后，它详细说明了激活优化的需求，并以一个说明性输入结束，该输入实践了示例优化。在少样本示例之后，目标优化具有相似的结构，而其测试输入将由 LLM 生成。

（2）图 4(b) 展示了在 PyTorch Inductor 中使用的测试生成提示。PyTorch Inductor 的测试输入格式是一个使用公共 PyTorch API（[INPUT SPECIFICATION]）的PyTorch 模型（[TARGET INPUT]）。接下来，指定激活优化 `permute_linear_fusion` 的测试输入需求，辅以一个可以触发此优化的说明性模型。提供的少样本示例帮助 LLM 以所需格式生成测试。此外，示例可以帮助LLM 学习优化需求描述与能够触发它的相应测试输入之间的关系。

 图4 WhiteFox的测试生成提示模板

3. 反馈循环 

（Feedback Loop）

引入反馈循环的动机：在每次迭代中，当发现新生成的测试能够触发目标优化时，将其收集为未来测试生成提示的少样本示例候选。通过将这些成功触发优化的测试纳入提示中，可以增强对生成型LLM 的针对性指导，使其能够生成更多触发目标优化的输入。

具体实现：WhiteFox 在迭代测试生成过程中将成功触发相应优化的测试作为补充示例纳入其中。

（1）执行测试，检测优化是否触发：生成的测试程序会被编译并执行，通过插桩记录优化触发情况。若优化被触发，则该测试程序被标记为“少样本示例候选”，并用于后续针对该特定优化的测试生成迭代。

（2）构建反馈提示：每次迭代中，如果当前优化有触发输入，WhiteFox 会选择几个触发输入作为示例（默认为 3 个），这些示例触发输入将与目标优化的指令和需求总结（与之前的提示相同）一起插入到图 5 所示的提示中，并用于生成下一批测试输入；如果某个优化没有触发输入，WhiteFox 将在后续迭代中继续使用初始提示（图 4），直到找到能够触发该优化的输入为止。

图5 加入反馈循环的测试生成提示模板

触发样本选择策略：

并非所有触发示例在指导LLM 生成新的有价值的触发测试方面都同样有效。评估其有效性的一个有用信号是当使用它们作为少样本示例时，新生成测试的触发率。为了在探索和利用之间找到平衡，有效选择触发示例至关重要。

因此，WhiteFox 采用了（改编的）多臂赌博机（MAB）算法，即 Thompson Sampling，作为触发示例的选择策略。beta 分布的概率密度函数可以正式写成如下：

• 当没有任何关于臂的先验信息时，选择标准beta 分布B(1, 1)（或等效的Uniform(0, 1)）作为其先验分布。beta 分布由两个形状参数α > 0, β > 0 参数化，它们表示历史试验中的成功和失败次数。

• 在抽取新样本并观察奖励（如果生成的测试成功触发目标优化则为1，否则为0）后，可以通过将α 或β 增加1来方便地更新后验概率，具体取决于样本是成功还是失败。

算法1 展示了示例测试选择过程：

（1）从每个后验分布采样θₜ（行2-3）；

（2）选择采样值最高的前N个臂作为本轮ExampleTests（行4）；

（3）用触发测试数量更新ExampleTests后验（行7-9）；

（4）基于ExampleTests的α、β均值初始化NewTriggerTests以减少探索开销（行10-14），假设新测试从“父”示例继承了有效代码模式；

（5）更新触发测试池（行15）。

4. 测试预言 

（Test Oracle）

在WhiteFox 中，错误表现为以下症状：

（1）结果不一致：编译优化传递可能因逻辑缺陷导致错误编译，产生语义不一致的机器代码，这种不一致可以通过差异测试来检测。具体来说，对于每个可编译和可执行的测试程序，在给定相同的输入集的情况下，交叉检查优化版本和非优化（或最小优化）版本的程序生成的输出。

（2）崩溃：让编译器和编译后的可执行文件意外崩溃是不可取的。因此，WhiteFox 积极捕获测试程序在编译时和运行时的崩溃信号，包括进程中止、段错误和意外的内部异常（例如 PyTorch 中的 INTERNAL_ASSERT_FAILED）。

总结来说，论文以两种模式编译每个测试输入：启用优化和不启用优化。将以下条件视为潜在错误候选：

•在优化编译或优化程序执行期间发生崩溃。

•两种模式之间的编译状态（通过/失败）不一致。

•两种模式之间的程序输出不同。

优化收集：

（1）目录定位：通过指定相关目录来收集特定优化的编译器源代码。例如，PyTorch Inductor 的优化传递源代码位于 `torch/_inductor` 目录下，而 TensorFlow-XLA 的优化源代码主要位于 `tensorflow/compiler/xla/service` 目录下。

（2）关键词匹配：通过简单的关键字模式匹配来识别执行优化的代码片段（例如函数）。例如，操作符融合是DL 编译器中的一项重要优化，通过搜索“fusion”或“fuse”来收集相关函数。此外，主优化调用的辅助函数也会被收集，因为它们可能揭示了激活优化的关键条件。

插桩：为了收集反馈循环所需的触发信息，在每个收集到的优化函数的入口处插入日志语句进行插桩。这样，在编译测试程序时，可以从日志中获取一系列激活的优化传递。

分析和生成LLMs：

（1）利用 GPT4 作为分析 LLM，并将温度设置为0。

（2）利用 StarCoder（StarCoder-15B）作为生成 LLM。在每次迭代中，让 StarCoder生成一批十个测试输入，并将温度设置为1。

少样本提示：

（1）对于每个目标编译器的需求总结和初始测试生成的少样本提示，论文选择一次性提示：从每个目标编译器中选择一个优化，手动编写需求描述和一个能够触发优化的演示输入测试。一个例外是PyTorch Inductor 有两种不同类型的优化（7 种使用传统的优化检查函数，54 种涉及模式匹配器）。因此，为每种类型分别设计两个提示，并根据优化类型为每个优化选择相应的提示。

（2）对于反馈提示：需求由分析LLM 生成，示例测试由生成 LLM 创建。在反馈提示中使用三个样本作为默认设置。

RQ1：WhiteFox 与最先进的 DL 编译器模糊测试工具相比如何？

RQ2：WhiteFox 中的所有关键组件是否都有效？

RQ3：WhiteFox 是否能够检测到现实世界中的错误？

1．实验设置 

表 1 被测DL编译器的细节

被测编译器：三个最流行的深度学习（DL）编译器：PyTorch Inductor、TensorFlow Lite 和 TensorFlow-XLA（对于 TensorFlow-XLA，由于其优化实现通常较长，仅选择了代码行数少于 400 行的优化，这是由于 LLM 上下文窗口大小的限制）。表 1 列出了被测 DL 编译器的概述。

基线工具：基于LLM 的 TitanFuzz 和基于符号规则的 NNSmith。

消融实验变体：WF-Mix（WhiteFox 的默认设置）、WF-NL（使用从混合格式中提取的自然语言）、WF-Code（使用从混合格式中提取的伪代码） 和 WF-Impl（直接向生成 LLM 提供实现源代码）。考虑到 PyTorch Inductor 拥有最多的优化，仅在 PyTorch Inductor 上进行消融研究。

环境：Ubuntu 20.04.5 LTS，配备 64 核 CPU、256 GB 内存和 NVIDIA RTX A6000 GPU。

模糊测试预算：默认设置为每个优化生成总共1000 个测试，分为 100 次迭代。

• 检测到的错误数量

• 触发的优化数量

• （优化）触发测试的数量

• 代码覆盖率：报告实现优化的源语言中的行覆盖率，PyTorch Inductor 使用 Python，TensorFlow Lite 和 TensorFlow-XLA 使用 C++。使用 Coverage.py 测量 Python 的行覆盖率，使用 GCOV 测量 C++ 的行覆盖率。

3．与先前工作的比较（RQ1）

表 2 在默认设置下和baselines的比较

默认设置

表2 比较了 WhiteFox 与基线工具在三个目标编译器上的默认设置下的表现。由于 NNSmith 的执行时间比 WhiteFox 的默认设置短，为了公平比较，展示了 WhiteFox-Mini 的结果，它为每个优化生成 100 个测试，而不是默认的 1000 个测试。表 2 中的“时间”列包括需求/测试的生成时间（包括 LLM 调用）和测试执行时间。

在优化触发方面，WhiteFox 在 PyTorch Inductor 和 TensorFlow Lite 中显著优于基线工具。总体而言，在被测编译器中，WhiteFox 在触发优化数量方面比现有测试工具高出最多 8.2 倍。

在时间成本方面，WhiteFox 消耗的时间比除 NNSmith 之外的所有其他技术都少。同时，鉴于 NNSmith 的性能较差，WhiteFox-Mini 仍然可以在更少的时间内触发比 NNSmith 更多的优化。

WhiteFox 在所有编译器上均优于基线工具，除了 TensorFlow-XLA，与 TitanFuzz 相比触发的优化少了两个，但仍然触发了 TitanFuzz 无法覆盖的 4 个独特优化。一个可能的原因是，为了与基线工具进行公平比较，对 TensorFlow-XLA 的目标优化进行了过滤，这些优化相对简单，有许多代表了实践中广泛使用的常见模型模式。因此，TitanFuzz 可以有效地触发这些优化，因为 TitanFuzz 利用 LLMs 生成类似于训练数据分布的人类可读程序。

此外，NNSmith 触发的优化数量最多，但主要依赖它总是输出带有冗余 reshape 操作的模型，并不意味着测试质量更高。

在每种方法触发的独特优化方面，对于PyTorch Inductor，WhiteFox 不仅完全覆盖基线触发的 7 个优化，还额外触发 34 个独特优化；在 TensorFlow Lite 中，WhiteFox 覆盖了基线触发的全部 9 个优化并新增 3 个；而在 TensorFlow-XLA 上，WhiteFox 覆盖了基线 26 个优化中的 20 个。

24小时测试期间：

表3 比较了 WhiteFox 与基线工具在 24 小时测试期间的表现。WhiteFox 在所有三个测试对象上表现最佳，在 PyTorch Inductor 和 TensorFlow Lite 上显著优于其他工具。

表 3 在24小时测试期间和baselines的比较

在代码覆盖率方面，WhiteFox 在 PyTorch Inductor 和 TensorFlow-XLA 上覆盖的代码行数比基线工具多出最多 19.9%。对于 TensorFlow Lite，WhiteFox 的表现略逊于 TitanFuzz（5.9%）。这可能归因于 TensorFlow Lite 中优化数量有限（13 个），本质上限制了 WhiteFox 的代码覆盖率探索，因为 WhiteFox 没有太多的白盒信息（即优化实现）来指导生成。

4．消融研究（RQ2）

表 4 需求描述格式在PyTorch Inductor上的影响

需求生成与测试生成：

需求描述的有效性：相比直接提供实现源代码（WF-Impl），使用需求描述的 WF-Mix、WF-NL 和 WF-Code 在生成触发测试方面表现更优。默认设置 WF-Mix 生成的触发测试比 WF-Impl 多 1.74 倍，并额外触发 7 个优化，凸显了需求描述在测试生成中的重要性。

混合格式的有效性：WF-Mix 在触发的优化数量和触发测试数量方面表现最佳，这突显了结合自然语言（NL）和伪代码进行需求描述的有效性。尽管 WF-NL 触发的优化比 WF-Code 多，但它生成的触发测试较少。因为NL 含有更多信息，可避免转换源代码时遗漏关键触发需求；而伪代码格式更便于生成 LLM 关联测试程序，从而提高触发测试数量。

分析LLM：使用 StarCoder 生成需求描述（WF-SC）时，触发的优化和测试数量均低于默认设置（GPT-4），验证了 GPT-4 在代码理解和自然语言转换方面的优势。尽管 WF-SC 低于 WF-Mix（默认设置），但仍优于 WF-Impl，证实了双模型基础设施可能比直接使用实现源代码更适合白盒编译器模糊测试，表明分离的需求生成阶段比直接使用实现代码更有效。

反馈循环：

图6 展示了一个条形图，详细列出了每个触发优化的触发测试数量，涵盖了本次消融研究中探索的变体范围。此外，论文还收集了这三个变体的覆盖率结果，如表 5 所示。

图 6 反馈循环和汤普森采样在PyTorch Inductor上的影响

表 5 反馈循环在PyTorch Inductor上的统计数据

反馈循环的有效性：包含反馈循环的WhiteFox 和 WF-Naive 生成的触发测试数量显著多于不包含反馈循环的变体（WF-No-Feedback），分别增加了 2.6 倍和 2.1 倍。这两种方法在代码覆盖率方面均优于 WF-No-Feedback，表明反馈循环可以指导 LLMs 生成更多样化的测试用例。

Thompson 采样的有效性：WhiteFox 采用 Thompson 采样选择触发示例，相比均匀采样（WF-Naive），触发测试数量提升 1.3 倍，覆盖 41 个优化中的 32 个，并取得更高代码覆盖率。

5．bug搜寻（RQ3）

表6 展示了 WhiteFox 在 PyTorch、TensorFlow-XLA 和 TensorFlow Lite 上的错误发现结果。截至目前，WhiteFox 已为这些编译器检测到 101 个错误。其中，92 个被确认为此前未知的错误，70 个已被修复。在 PyTorch Inductor 中发现的 79 个错误中，有 14 个是在其最新版本中发现的，10 个（12.7%）PyTorch 错误被标记为高优先级。在这 79 个由 WhiteFox 检测到的独特错误中，68 个是基线工具无法检测到的。对于 TensorFlow-XLA 和 TensorFlow Lite，基线工具只能发现 WhiteFox 发现的 22 个错误中的 1 个。

表 6 WhiteFox探寻到的bug总览

错误分析：

论文对PyTorch Inductor 的 101 个错误进行了全面分析，其中 79 个（78.2%）由 WhiteFox 检测到，且 68 个（86.1%）已修复。在 79 个错误中，仅 11 个（13.9%）可被现有工具覆盖，其中 10 个可由 TitanFuzz 检测到，3 个可由 NNSmith 检测到。

在68 个已修复的错误中，47 个（69.1%）位于优化代码中，这证明了 WhiteFox 在发现优化错误方面的有效性。在这 47 个优化错误中，只有 3 个可被 TitanFuzz 和 NNSmith 覆盖，凸显了 WhiteFox 在测试编译器优化方面的优势。此外，某些优化（如注意力模块）更容易出错，但更难被发现，WhiteFox 在这些模块中检测到了 5 个错误，暴露了开发者测试的不足。这表明结合 LLMs 的白盒模糊测试具有强大能力。

错误特征：

论文进一步研究了WhiteFox 检测到的错误的详细特征，包括崩溃、错误编译、优化失败、错误通过的优化和漏洞，如表 7 所示。

• 错误编译：优化后的程序返回与非优化程序不同的输出。

• 优化失败：启用优化时编译失败，而在不启用优化时编译有效。

• 错误通过的优化：优化成功编译无效模型。

• 漏洞：除了6 个可用于 DoS 攻击的崩溃错误外，在错误通过的优化中还检测到了另外 5 个越界读取漏洞。

  
  

表 7 WhiteFox探寻到的bug特征

不会修复的错误：

在PyTorch Inductor 中，一个错误是由于编译器不支持量化 API，另一个是由于操作符中的未定义行为，第三个是因为开发者认为WhiteFox的输入无效，尽管优化编译了模型并返回了不同的结果。

在TensorFlow Lite 中，两个错误源于其不保证输入输出顺序的特性，另一个是优化后的输出具有不同的形状，这在 PyTorch Inductor 和 TensorFlow-XLA 中都是罕见且不被预期的。

错误示例：

图 7 WhiteFox探寻到的bug示例

1. 真实世界的影响

PyTorch 团队认可 WhiteFox 并请求将其集成到 PyTorch Inductor 开发流程中。为此，作者扩展了 WhiteFox，支持最新版本的 PyTorch Inductor 及 38 个新优化。

2. 一般性：LLVM的案例研究

为了展示WhiteFox 的通用性，论文实现了一个用于测试 LLVM 的 WhiteFox 原型。在基线工具方面，选用了 YARPGen 以及 GrayC。测试的 LLVM 版本是 LLVM-18-20230818-nightly，实验环境与之前描述的设置一致。

优化触发：

表8 展示了 LLVM 优化的触发结果与基线工具的比较。与 DL 编译器的结果类似， WhiteFox 触发的优化数量比基线工具多 6.5 倍，同时时间成本更低。这证明了 WhiteFox 在不同编译器上的有效性和潜力。

表 8 在LLVM优化中和baselines的对比

错误检测：

WhiteFox 检测到了 6 个 LLVM 错误，其中 2 个被确认为此前未知的错误，3 个待确认，1 个不会修复。图 7(e) 展示了一个已确认的 LLVM 错误，该错误仅在测试程序通过足够大的索引引用一个大数组时才会显现，导致 LLVM 优化后崩溃。攻击者可以通过构造特定的输入程序来利用此漏洞，使启用即时编译（JIT）的系统崩溃，从而实现拒绝服务（DoS）攻击。

3. 局限性与未来工作

WhiteFox 不仅适用于编译器优化的白盒模糊测试，还可能扩展到其他编译器代码或复杂软件系统。对于回归错误，可通过设置更改分支为目标并利用 LLMs 分析触发条件来部署 WhiteFox。然而，与优化相比，任意函数的高级输入与低级实现的映射可能不明确，这是其面临的挑战。未来可探索利用 LLMs 推断这种映射（如借助文档等辅助信息）以及触发条件。

另一个未来方向是将传统模糊测试方法作为外部工具，以提高测试生成效率。由于调用较小LLMs 的成本高于传统技术，这种策略可提升性能。例如，可利用 WhiteFox 总结优化触发规则，指导传统模糊测试框架（如 NNSmith）的输入生成。

WhiteFox 是首个实用的白盒编译器模糊测试工具，专注于测试编译器优化。它采用多智能体架构，其中分析 LLM 提取优化触发模式，生成 LLM 高效合成测试程序。评估结果表明，WhiteFox 在 DL 编译器和传统 C/C++ 编译器上均表现出色。截至目前，WhiteFox 已发现 101 个 DL 编译器错误，其中 92 个此前未知，70 个已修复，验证了其强大的错误检测能力。

BAZZAFL：通过面向漏洞的种子分组将模糊测试活动导向漏洞

通过命令行反馈利用大语言模型提高编译器选项黑盒模糊测试

Beyond REST：一种用于全面API漏洞模糊测试的工具APIF

阅读原文

跳转微信打开

BAZZAFL的核心思想是维护多个种子组，每个种子都在某一目标上表现最好。在这些种子组中，BAZZAFL通过多目标优化的方式，优先测试最有可能包含漏洞的代码区域，并根据香农熵自适应地分配能量给种子组中的不同种子。

在变异过程中，BAZZAFL倾向于变异那些可能改变执行状态的字节。通过这些创新，BAZZAFL逐步推动模糊测试朝着更接近漏洞触发点的方向发展。

覆盖引导灰盒模糊测试作为最有效的漏洞检测方法之一，其核心假设是通过提升代码覆盖率增加漏洞暴露概率。

现有研究主要通过优化调度策略、路径约束处理等方式提升覆盖率，但代码覆盖率本身存在效率瓶颈——理想的漏洞检测需同时满足两个条件：

1）到达含漏洞的代码区域；

2）满足触发漏洞的特定执行状态（如内存值/寄存器值等运行时信息）。然而多数CGF方案仅关注代码覆盖，忽略执行状态分析。

检测多种类型的漏洞是一个多目标优化问题。

一方面，不同类型的漏洞在模糊测试过程中可能会相互冲突。例如，某个代码区域可能是基于漏洞类型A的最可疑位置，但基于漏洞类型B却是最不可能的位置。

另一方面，一个输入可能同时影响多种类型的漏洞。例如，由于类型A和B的漏洞位于同一个代码区域，某个输入可以同时影响这两个漏洞。然而，尽管它们位于同一代码区域，但相同的输入不太可能同时触发这两种漏洞，因为它们需要不同的执行状态。

本文提出了BAZZAFL。为了应对一个种子无法同时表示多种漏洞类型的问题，BAZZAFL将具有相同执行路径但不同漏洞度量的种子组织成种子组。组中的所有种子执行相同的代码区域，每个种子仅负责其自身类型的漏洞。

图3-1展示了常见程序中可能存在的两个漏洞。一个可能的内存消耗错误可能出现在D块，当请求的内存过多时。另一个错误是算法复杂度错误，可能出现在G块，因为函数process_input()的执行次数与输入相关。

代码覆盖率作为唯一指标，模糊测试倾向于优先选择覆盖范围最大的种子（g1）。

但关键错误存在于ACDFG（g2）和ACEFG（g3）路径，导致错误检测效率低。

现有方法使用单一种子，无法优化不同错误类型的触发。因此，一个更好的解决方案是使用多个指标来评估种子。

图3-1 动机例子

图4-1 BAZZAFL的工作流程

基于种子组优化种子选择和变异。种子组的组织标准是所有种子都执行相同的执行路径。

主要包括三个组件：种子组优先级排序、能量分配调度和字节推断。

种子组优先级排序旨在选择那些其种子更有可能在错误检测上取得更好表现的获胜组。

选定种子组后，能量分配调度用于确定每个种子在组中分配的能量。

在种子变异过程中，字节推断用于推断与每个目标错误相关的字节。字节推断旨在进一步探索可疑的执行状态。

1．Seed Group

在检测多种类型错误的多目标问题中，每个目标都需要被量化，以便不同目标之间可以进行比较。

包含五个种子的种子组可以执行所有类型错误的最可疑执行状态。该组中的种子具有相同的执行路径，但组中的以某个错误为导向的种子在该错误度量上表现得比其他种子更好。

图4-2 种子分组的过程

边覆盖：发现错误的第一步是探索可疑的代码区域。为了衡量种子在边覆盖方面的质量，设置了两个度量，分别是执行速度（m1）和种子所覆盖的边数量（m2）。

内存违规错误（MV）：当内存被指针错误地访问时，就会发生内存违规错误。因此，如果模糊测试关注内存访问操作，即为更多内存访问的代码区域分配更多能量，它可能会发现更多的内存违规错误。为了衡量种子在MV错误方面的质量，作者使用内存访问操作的次数作为度量（m3）。

越界错误（OOB）：OOB是内存违规错误的一种特定类型，它发生在读取或写入越界的字节时。直观地说，访问更接近内存边界的输入比访问远离边界的输入更可能触发越界错误。为了衡量种子在OOB错误方面的质量，使用一个比率来衡量内存访问距离边界的远近（m4）。该比率定义为r = cur/max，其中cur是内存块中的当前索引，max是最大大小。

内存消耗错误（MC）：MC是一个空间复杂度问题，当程序执行时消耗了过多或无法控制的内存时，就会发生这种错误。由于该错误消耗了过多的内存，它使得攻击者可以发起拒绝服务（DoS）攻击。为了衡量种子在MC错误方面的质量，使用已分配内存的大小作为度量（m5）。

算法复杂度错误（AC）：AC是一个时间复杂度问题，它发生在触发最坏情况的算法行为时。如果一个输入触发了算法复杂度错误，该输入将需要很长时间来完成执行，因为有太多的基本块需要执行。因此，它也可以被攻击者利用来发起DoS攻击。为了衡量种子在AC错误方面的质量，使用已执行的基本块数量（m6）。

2．Seed Group Prioritization

将种子组的优先级排序视为一个多目标优化问题。在多目标问题中，可以获得一组最优解，或者称为帕累托最优解，这有助于在模糊测试中优先选择一组种子组。

采用非支配排序方法来为不同轮次找到帕累托最优解。该问题可以定义为：

F(g)是一个包含k个目标函数的目标向量，即选择种子组的k个度量。BAZZAFL为每个种子组设置了六个度量（即k=6）。理想情况下，这六个度量有助于模糊测试优先选择种子组。

1.非支配排序方法：一种常用的多目标优化解决方案是计算帕累托前沿。帕累托前沿是一个非支配的解，定义为：

其中，g’支配g当且仅当对于目标向量[m1, m2, …, m6]：

在模糊测试的背景下，帕累托前沿是动态变化的，因为每个种子组中的度量值在模糊测试过程中发生变化。

因此，使用非支配排序进化方法来计算动态的帕累托前沿。基本上，每个种子组都分配一个等级，初始值为0。在计算帕累托前沿的过程中，如果g’支配g，那么g的排名就增加1。

对于每个模糊测试活动，BAZZAFL优先选择具有最小排名的组。

新添加的种子组在下次计算帕累托前沿时进行排名。这可以节省计算帕累托前沿的时间，因为每次添加新种子时，无需更新所有种子的排名。

2.放松的多目标问题：然而，在某些情况下，这六个度量同时满足的条件过于严格，导致没有优先排序的种子组。具体来说，所有的排名相同，因为没有种子能够支配其他种子。根据图4-3的结果，只有少数种子位于0级，表示如果不放宽约束，几乎无法得到更好的种子在帕累托前沿中。

因此，如果当前的优先级排序无法选择具有最小排名的获胜组，BAZZAFL通过逐渐去除目标向量F(g)中的一个度量来放宽约束。优先删除那些不太可能触发错误的度量。

首先删除度量m1（执行速度），因为最终目标是发现错误。如果去除m1仍然不能选择获胜组，作者将删除m2（覆盖的边数量）。如果仍然无法选择获胜组，m6（执行的基本块数量）将是第三个被删除的度量，因为AC比其他错误类型的发生概率低。最后，将删除m3（内存访问操作数量），因为OOB比其他类型的内存违规错误更可能发生。

保留至少两个度量m4（衡量内存访问距离边界的远近的比率）和m5（已分配内存的大小），以确保问题仍然是一个多目标问题。

图4-3 不同级别的支配约束的总支配成功百分比

3．Power Schedule for Individual Seeds

当选定一个种子组后，受到ENTROPIC的启发，BAZZAFL将模糊测试理解为一种学习过程，并基于香农熵来计算能量，从而优化能量分配。具体而言，如果一个种子能够揭示程序的更多信息，则该种子将获得更多的能量。

1. 香农熵：ENTROPIC是一个专注于更大代码覆盖的模糊测试工具。它将程序中的每个边视为一个物种，边的发现类似于物种发现。如果输入覆盖了边Di，则该输入被认为属于物种Di。由于一个输入可以覆盖多个边（即一个输入属于多个物种），根据香农熵公式 

ENTROPIC计算种子t的熵为：

4．Byte Inference for Mutation

使用与AFL++相同的变异操作符来进行变异。

BAZZAFL推断出可以改变与漏洞相关的度量值的字节。字节推断基于这样一个观察结果：种子中的只有一部分字节与漏洞度量相关，这表明变异所有字节是浪费时间。

作者考虑在确定性阶段对字节推断的变异操作，包括位级、字节级和字级的变异操作。具体来说，选择那些已知变异字节位置的变异器，如FLIP_BIT和SWAP32。

对于每个面向漏洞的种子，字节推断更有可能变异与其目标漏洞相关的字节。

请注意，由于确定性变异器的低效，仅对一个种子（即边覆盖种子）进行字节推断，然后将结果用于变异种子组中的其他面向漏洞的种子。

至于模糊测试的其他阶段，大多使用非确定性变异器进行测试。

BAZZAFL首先记录变异字节的位置，然后根据漏洞度量的变化确定变异位置是否与相应的度量相关。

如果一个字节的变化导致MC度量值发生变化，BAZZAFL将记录该字节为种子s的相关字节。在变异针对MC设计的种子s时，BAZZAFL更可能变异与MC漏洞相关的字节。

基于AFL++ 4.01a 实现了BAZZAFL，利用LLVM 13 对目标程序进行插桩，获取边覆盖和漏洞度量的反馈。

使用与AFL++相同的插桩方式来获得边覆盖。

对于内存违规漏洞，对操作内存的指令进行插桩，并计数这些指令。具体而言，在操作内存的函数调用处进行插桩，如malloc、free和memcpy。此外，作者还在可能操作内存的指令处进行插桩，利用LLVM中的mayReadFromMemory()和mayWriteToMemory()。

对于越界错误，作者在数组和结构体等聚合数据类型处进行插桩，以获取偏移量（即内存访问的当前地址）和大小（聚合数据的总大小）。作者使用偏移量/大小的比值来量化越界的可能性。

对于内存消耗漏洞，作者在分配和释放内存的指令处进行插桩，以获取已分配内存的总大小。

对于算法复杂度漏洞，作者计算输入覆盖的基本块数。

1．Experiment Setup

表5-1 用于评估的程序

在Ubuntu 18.04上，使用Intel(R) Xeon(R) Gold Silver 6230R CPU进行实验。

如表5-1所示，在24个程序上运行模糊测试，这些程序来自UniFuzz。

对每个目标程序运行每个模糊测试器10次，每次运行24小时。所有模糊测试器都使用提供的相同初始种子。

基准模糊测试器包括AFL、AFL++、MOPT、MemLock、FuzzFactory和SLIME。

2．RQ1: Effectiveness of BAZZAFL

表5-2 10次实验中模糊器暴露的独特崩溃和错误数量

如表5-2所示，BAZZAFL发现了最多的唯一崩溃和漏洞。BAZZAFL共发现了179个漏洞，覆盖了21个程序，发现的漏洞比第二名SLIME多62个（即多发现了53%的漏洞）。

尽管BAZZAFL更多地关注漏洞，但它仍然保持了代码发现的能力。如表5-3所示，BAZZAFL比第二好的模糊测试器AFL++多发现1.75%的边。

至于执行速度，BAZZAFL比其他模糊测试器平均快37.15%，仅比最好的模糊测试器AFL慢0.6%。

表5-3 10次实验中模糊器的平均边覆盖数和执行速度

表5-4展示了作者实验中发现的漏洞信息，包括CVE ID、漏洞原因以及漏洞所属的类别。

BAZZAFL暴露了九种类型的漏洞，包括使用后释放、内存访问违规、（栈、堆或全局）缓冲区溢出、缓冲区过读、内存泄漏、错误分配、作用域外使用、栈溢出、内存不足和浮点异常。

在这九种漏洞中，使用后释放和内存访问违规可以通过内存违规种子进行攻击；

栈溢出可以通过算法复杂度种子进行攻击；

内存不足、内存泄漏和错误分配可以通过内存消耗种子进行攻击；

缓冲区溢出可以通过越界种子进行攻击。

表5-4  BAZZAFL发现的典型错误类型

3．RQ2：Significance of Seed Groups

图5-1 当一个面向bug的种子被禁用时，边覆盖、唯一崩溃和bug数量的比较

在本节中，通过消融实验探索种子组中每个单独种子的影响。禁用种子组中的一个面向漏洞的种子，并与原始种子组进行对比实验。将禁用面向漏洞的种子的方案表示为BAZZAFL-，其中可以是MV、AC、MC和OOB之一。

总体而言，当种子组中的所有种子都启用时，漏洞发现的效率更高。在50%的程序中，BAZZAFL比BAZZAFL-*发现了更多的唯一崩溃和漏洞。

在本节中，通过消融实验展示了放宽方法在种子组优先级中的重要性。对每个程序运行24小时，并计算每个级别上的成功支配次数。

结果如图5-2所示，其中级别0表示满足所有6个约束。从级别1到级别4，按顺序每个级别放宽一个约束。在几乎所有程序中，级别0的支配成功率都低于3%。当级别增加（即约束减少）时，更多的支配成功发生。

图5-2 不同级别的支配约束的总支配成功百分比

5．RQ4：Efficiency of Information Discovery

在本节中，通过最大时间段来衡量模糊测试器的效率，这段时间是模糊测试器未能发现新信息的时间，称为“空闲时间”。当模糊测试发现新的边覆盖或在漏洞度量上达到更大的值时，就会发现新信息。

如果一个模糊测试器长时间无法发现新信息，则认为该模糊测试器效率低下。图5-3是一个小提琴图，显示了在10次实验中的平均空闲时间的概率密度。

在图中列出的10个程序中，BAZZAFL在所有程序上都比其他模糊测试器更高效地发现新信息，即BAZZAFL具有最小的空闲时间中位数。

图5-3 空闲时间的Violin图

此外，作者进行了字节推断的消融实验，结果如表5-5所示。度量更新计数指的是每个种子组中漏洞度量的更新次数，表示是否有任何漏洞度量得到更新。最大度量更新计数代表全局范围内最大漏洞度量的更新次数。

表格中的前面值表示没有任何字节推断的结果，而后面的值表示在相应度量下进行字节推断的结果。ALL表示对所有4种漏洞度量进行字节推断。

根据表格，对于大多数程序和漏洞度量，字节推断的度量更新计数比基线更高。这证明了字节推断在提高信息发现效率方面的有效性，并且与BAZZAFL的能量调度配合使用，使漏洞度量能够得到全面的利用和开发，并高效地最大化漏洞度量值。

表5-5 不带字节推理和带字节推理的不同路径BUG度量和全局最大BUG度量的平均更新次数

在本文中，作者提出了BAZZAFL，旨在优化多目标模糊测试的调度，包括边覆盖和多种类型的漏洞。BAZZAFL基于种子组开发了三个组件，分别是种子组优先级、能量调度和字节推断。评估结果表明，BAZZAFL成功地优化了种子选择和能量调度，能够在多个目标之间进行有效调度，并且识别出了最多的独特漏洞。

通过命令行反馈利用大语言模型提高编译器选项黑盒模糊测试

Beyond REST：一种用于全面API漏洞模糊测试的工具APIF

SELECTFUZZ:采用选择性路径探索的高效定向模糊测试

阅读原文

跳转微信打开

编译器在软件构建中扮演着核心组件的角色，编译器中的缺陷可能会导致编译失败，并引入潜在的安全漏洞，进一步影响编译后程序的质量和功能。因此通过软件测试和安全分析来确保其可用性和可靠性至关重要。目前，大多数研究集中在编译器在编译各种测试用例时的鲁棒性上，对编译器选项的可靠性缺乏关注。尽管一些研究人员已经在这方面做出了努力，但由于对编译器命令反馈信息的利用不足，导致测试效率低下，阻碍了更多样化和深入的测试。

在本文中，作者提出通过利用命令反馈来增强编译器选项黑盒模糊测试。其中命令反馈包括命令行消息和编译文件。命令行消息包括错误消息和标准输出。为了弥合错误与可能崩溃之间的差距，并使编译器能够自动修复运行时错误，提出了错误修复模块，将根据错误消息修改编译器命令行选项。为了挖掘隐藏在成功结果中的错误和崩溃，并减少运行时间，提出了选项修剪模块，将删除那些强制输出、掩盖崩溃的选项。上述两种方法都利用了大语言模型（LLM），并根据命令反馈消息和选项描述执行相应的操作。

本文实现的原型在4个版本的LLVM上进行了评估。实验表明，与基线相比，本文的方法显著提高了崩溃检测率，减少了假阴性，并提高了编译的成功率。迄今为止，该方法已经识别出9个以前未知的漏洞，其中8个已被分配CVE编号，1个在报告后得到了修复。

编译器模糊测试有两种接口：编译测试用例和编译器选项。大多数研究专注于生成多样化且格式良好的测试用例，以在模糊测试过程中提高代码覆盖率，但往往忽略了编译器选项的测试，实际上，编译器选项能够启用特定功能（如优化），提供更大的测试多样性。此外，现有的黑盒模糊测试方法主要依赖生成的二进制程序中的变化作为反馈来引导测试过程，未能充分利用编译器命令输出中的关键信息，例如错误信息和成功输出。

而针对上述的问题，作者提出了本文的方法：

(1)深入研究了现有编译器选项模糊测试方法中大量的假阴性，并揭示了这些假阴性发生的关键原因。

(2)提出了一种新方法，利用大语言模型自动化执行选项修复和选项修剪的过程，从而减少假阴性，并提高编译器选项模糊测试的效率。

(3)通过性能实验和消融研究进行评估，与基准方法Cornucopia进行比较，评估在崩溃检测、减少假阴性以及提高编译成功率方面的效果。

图 1  本文方法的工作流

本文的工作流如图1所示，包含了测试过程中的关键阶段。该方法从生成选项列表开始，选项列表来源于选项描述文档，包含了所有可供编译器直接在模糊测试中使用的选项。接着，模糊测试器利用选项列表中的选项集合生成命令行选项的组合，并将指示符替换为指定范围内的随机数据。最后，测试中的编译器将被调用，使用各种选项组合，并监控是否发生崩溃，记录所有崩溃输出以及错误和成功的结果。

除了常规流程外，本文提出了两个模块来减少假阴性：选项修复和选项修剪。选项修复模块利用编译器测试产生的命令反馈中的错误信息。基于LLM，依靠网页搜索引擎和本地编译器选项描述文档，执行检索增强生成（RAG），最终提供如何修复相应命令行选项组合的建议，以消除错误。选项修剪模块利用标准输出和已编译文件来判断是否存在阻碍崩溃输出的信息，或者是否为无效编译导致空输出文件。同时，使用LLM对选项描述文档进行语义对齐，通过差异测试识别出控制相应消息打印的特定选项。通过从选项列表中去除这些选项以减少时间消耗并揭示隐藏的崩溃。

1．初步模糊测试

本文的方法从初始的模糊测试阶段开始，该阶段对收集后续过程所需的关键信息至关重要，由四个不同的阶段组成。

（1）生成选项列表：解析选项描述文档以生成选项列表作为语料库。选项描述文档可以来源于帮助页面和在线文档。对于不需要值的选项，通过包含或排除来使用；对于一个值有范围的选项，则列举该选项的所有可能值并将其包含在选项列表中；对于有些值过分广泛的选项，用指示符<int>和<str>来描述。

（2）生成选项组合：使用选项列表中所有可能的选项生成选项组合

（3）变异：根据选项变异模块进行变异。当模糊测试器遇到指示符时，它会将随机种子中的特定部分解析为“< str >”的字节串，并使用取模操作将“< int >”的值限制在指定范围内。

（4）编译并收集命令反馈：使用生成的选项组合执行编译器并收集所有命令反馈，包括命令行消息和编译文件。持续监控运行状态，以确保及时报告发生的任何崩溃。

2．选项修复

在初步模糊测试阶段之后，利用结果测试数据（包括编译器命令反馈消息和编译输出文件）来帮助修复编译错误。选项修复过程与模糊测试循环并行工作，为模糊测试器提供修复后的选项组合进行执行。通过这种方式，可以发现隐藏的崩溃，并且甚至可以实现自动编译。

选项修复过程依赖于两个新集成的组件：一个用于查询的LLM，能够根据测试结果提供潜在的修复方案；一个供LLM使用的网络搜索引擎，用于获取在线资源以提高准确性。如图2所示，选项修复模块包括以下四个步骤。

图 2 选项修复模块工作流

（1）修复查询：首先，报告错误的测试结果被用于查询LLM，以获取这些错误的原因及解决方法。为了与LLM有效互动，需要使用提示语，理想的提示语应尽可能详细，包括示例和具体指令，如图3所示。

为了纠正错误，本文定义了两种主要的候选操作：“删除”和“更改值”。“删除”操作涉及完全移除有问题的选项，而“更改值”操作则是为该选项选择一个不同的适当值。为了避免开启更大的选项搜索区间，该方法暂不考虑“添加其它选项”。

图3 选项修复的提示语

（2）错误信息查询：LLM利用搜索引擎搜索与错误信息相关的额外文章。通过进行实时在线搜索，LLM能够收集有关错误原因和潜在解决方案的更全面信息。这些额外的信息增强了LLM响应的可靠性。

（3）描述检索：在进行错误信息的在线查询后，LLM获得了对错误原因和潜在解决方案的初步理解，但这些信息仍需进一步验证。检索增强生成（RAG）通过参考其训练数据源之外的权威知识库来增强LLM回答的可信度。本文将编译器选项的描述文档视为这样的外部知识库，有利于判断是删除该选项，还是将其更改为不同的值。

（4）错误选项修复：一旦LLM处理了查询并从描述文档中检索到相关信息，它就会生成修复选项的策略，如图3所示。输出结果包括与错误相关的选项以及需要采取的具体行动，如删除或更改值。

接下来，对识别出的选项应用指定操作，并通过操作选项生成器重新运行编译器。如果错误未完全解决，将启动迭代过程：当错误消息不变时，触发三层循环提示，重复查询，直到出现新错误消息或同一错误消息出现三次。若出现新错误，则为其启动新的三层循环提示；若同一错误出现三次，则结束提示并处理下一个错误案例。这一迭代过程旨在有限时间内尽可能解决更多错误。

3．选项修剪

选项修剪阶段的目的是删除会导致强制信息输出的选项，从而提高效率，减少被隐藏的崩溃。选项修剪在下一轮模糊测试之前以串行方式执行，它准备了一个修剪后的选项列表，用于在模糊测试过程中生成测试用例。该模块同样是基于LLM构建的，如图4所示，包含以下四个步骤。

图4 选项修剪模块工作流

（1）语义对齐：为了修剪不相关的选项，首先通过语义对齐识别输出类型的选项。利用LLM分析选项描述文档，判断选项是否属于输出类型；从输出消息开头的前十行中提取信息，确定输出类型，并与选项描述文档进行语义对齐，识别对应的输出选项；通过差异测试验证已识别的选项，确保其准确性。该过程中设计的提示语如图5所示。

图5 选项修剪的提示语

（2）选项差异测试：差异测试从崩溃概念验证（PoC）开始。一旦通过语义对齐识别了选项，通过将每个选项单独添加到崩溃PoC中，检查它是否会导致崩溃或改变状态。如果修改PoC后没有发生崩溃，则新增的选项被验证为阻碍崩溃发现，必须进行修剪。

（3）选项列表修剪：将待修剪的选项从选项列表中删除。由于仍然存在被修剪的选项可能导致崩溃的可能性，所以必须收集历史运行状态数据，以决定是否移除或保留它们，以便触发更多的崩溃。如果某个选项曾经出现在导致崩溃的组合中，则不建议移除它。若选项不与任何崩溃相关联，则更适合将其移除。

（4）种子稀疏化：将种子字节稀疏化到一个新的分布空间中。该方法涉及减少种子值的范围，使得种子主要由二进制“0”组成，且包含较少的二进制“1”。这意味着生成的选项组合中使用的选项数量将减少，并且本文的实验表明，这种方法在一定程度上是有效的。

4．来自LLM的错误答案的影响

在选项修复和修剪过程中，LLM的输出可能存在的随机性和错误答案。

在选项修复过程中，LLM可能提供错误答案（如删除错误选项或替换错误值），导致原始错误保持不变或引入新错误。但本文设置了三层循环机制，通过三层循环提示过程处理错误，每个错误最多只有三次修复机会，若未解决则结束该进程，时间和资源消耗有限。该过程对LLM错误答案有一定的弹性。

在选项修剪过程中，LLM的错误结果可能会提供与编译器输出无关的选项，这些选项将通过选项差异测试来处理。若一个选项通过了差异测试，则会检查历史崩溃信息，确认其是否是已知崩溃的原因，可能潜在触发漏洞的选项会被保留。

本文在三个实验中评估了本文原型的实现。首先，检查是否能在基准测试中检测到比现有工具更多的崩溃，并比较其与现有工具在假阴性方面的表现。其次，分析本文方法所提出的各个组件是否促进该有效性。最后，研究是否能够在现实世界中发现新的漏洞。

1．实验设置 

环境：所有实验均在使用Intel Xeon Gold 6230R CPU@104×4 GHz和256 GB内存的专用服务器上进行。 对每个目标和测试用例的组合并行进行了模糊测试，使用相同的配置在20个CPU核心上运行了2小时。

目标：在C/C ++编译器框架LLVM中进行了评估，专门针对其内部工具链，其中包括Clang，Opt，LLC，LLI等工具。本文仅对命令行选项进行模糊测试，因此会使用一组没有语法错误的良性测试用例集进行编译。 这种方法能够消除测试案例的影响并专注于选项。

基线：由于本文是基于Cornucopia测试结果的观察，并且还基于cornucopia来构建本文的方法，所以选择cornucopia作为比较基线。本文方法包括两个新增模块：选项修复和选项剪枝。选项剪枝模块又包含两部分：种子稀疏化和选项列表剪枝。因此，在消融研究中，共有八个版本的方法来展示。

指标：采用触发的崩溃crash数量作为度量标准，因为这本质上是模糊测试的目标。独特崩溃的数量是另一个评估指标，因为不同根本原因导致的崩溃数量可以在一定程度上反映黑盒测试中的代码覆盖率。

2．实验1：有效性

表1 不同测试结果的统计

表2 不同测试结果转换的统计

本文的方法旨在改善错误和成功测试结果中的假阴性案例，为了证明该方法的有效性，分别对错误和成功测试结果的变化进行了全面的统计分析，并记录了崩溃的次数。

表1统计了基准Cornucopia和本文方法的测试结果，并比较了二者之间测试结果数量的变化。表中数据显示，本文的方法能够发现比基准显著更多的崩溃，增加了569.60%。错误结果数量的减少表明方法有效地解决了错误。表2说明，通过本文的方法，Cornucopia获得的大约18.73%的成功结果被转化为崩溃或无法处理的错误，大约47.67%的错误结果被转化为成功编译或崩溃。这些数据展示了本文工作在实现自动化成功编译方面的有效性。

独特崩溃的数量是评估模糊测试效果的重要指标之一。LLVM在崩溃时会生成“堆栈转储”，可以在修剪地址信息后通过比较堆栈跟踪来对崩溃进行分类。作者收集了从成功/错误结果到崩溃结果的转换数据，并将其记录在表3中。

通过本文的方法，观察到大约8.23%的原始成功结果和14.52%的原始错误结果被转化为崩溃，从而导致崩溃总数显著增加。独特崩溃的数量增加了245.36%。

表3 唯一崩溃数量的统计

3．实验2：消融实验

在5.2中，选择了一组多样化的通用测试用例进行编译，其中包括来自 coreutils及其他软件包的代码片段。在消融实验中，仅选择了来自 augeas-tools软件包的单个代码片段augmatch，以使实验规模更小且更高效。

本文将八个版本进行对比：基线方法Cornucopia、带有种子稀疏化的基线方法、带有选项列表修剪的基线方法、同时包含两部分选项修剪的基线方法，以及另外四个对应的版本，这些版本额外包含选项修正模块。

如表4所示，记录了每个实现版本的总崩溃次数及唯一崩溃次数。括号中的数字表示唯一崩溃的数量。

表4 消融实验中的崩溃数量统计

选项修正模块在模糊测试中的作用更多是优化而非核心支持，而选项修剪模块则在整个模糊测试过程中对崩溃发现的贡献最为显著。具体而言，选项修剪将总崩溃次数从19次（包含6个唯一崩溃）显著提升至142次（包含20个唯一崩溃），而选项修正仅将总崩溃次数增加至44次（包含8个唯一崩溃）。尽管如此，表4下半部分展示了包含选项修正模块的四个版本相较于上半部分的版本，发现了更多的唯一崩溃，这表明该模块在提升测试效果方面具有一定的有效性。

在选项修剪过程中，选项列表修剪操作对崩溃发现能力的提升贡献最为显著，且具有持续性。相比之下，种子稀疏化仅在特定条件下表现出有限的效果，甚至在仅应用于基线方法时，导致崩溃次数从19次（包含6个唯一崩溃）下降至5次（包含3个唯一崩溃）。为了在实际应用中平衡效果与性能，仅对50%的种子执行种子稀疏化操作。

因为最终导致崩溃的实际触发命令包含大量选项，其中导致崩溃的关键选项隐藏在众多可用选项中。为了进一步研究本文方法如何从误判为非崩溃的测试结果中发现崩溃，以及如何处理崩溃以确定其是否是独特的，再次展示一个来自实验的真实案例。

（1）案例研究：对最新版本的LLVM进行了初始模糊测试，选择图6所示的命令作为分析起点。所有带有冗余打印消息的成功结果都会经过选项修剪模块处理。在所有成功结果中，大约 26.85%与图 6(a) 所示的命令消息相同。

通过选项修剪模块的语义对齐阶段，自动识别出选项“--version”是这些消息的触发因素。选取初始模糊测试阶段检测到的一次崩溃，并在 PoC命令中添加“--version”以检查崩溃是否仍然发生。结果发现崩溃消失了，这证明“--version”可能会掩盖崩溃。因此，该选项被从选项列表中移除。在去除“--version”后提取结果，使其从图 6(a) 过渡到图6(b) 中的错误结果。通过与LLM的交互修正该问题。

随后，编译命令再次成功执行，但它生成了一个空的编译文件，并伴随新的命令反馈消息，如图6(c) 所示，这表明命令仍然存在问题。在选项修剪模块的语义对齐阶段，识别出该输出消息由“--opt-bisect-limit”选项引起，因此将该选项从选项列表中移除。最终成功触发了一次崩溃，如图6(d) 所示

图6 一个真实案例的研究

（2）真实漏洞：对LLVM 框架的四个版本（12.0.0、14.0.0、16.0.6、18.1.2）进行了全面测试，检测到的漏洞总体统计数据列于表5。由表可知，检测到的漏洞总数在较高版本中呈增加趋势，这可能是由于 LLVM 版本升级后选项数量的增长，例如：LLVM-12.0.0具有1148个选项，LLVM-14.0.0具有2385个，LLVM-16.0.6具有2009个，而LLVM-18.1.2具有2594个。另一个可能的原因是在选项修正模块的检索增强生成阶段，缺少在线支持，导致修正效果受到一定影响。

表5 在不同版本LLVM中检测到的bug的统计数据

所有唯一崩溃均由脚本根据堆栈转储自动计算，而所有已确认的漏洞则经过人工分析，因此数量相对较少。本文主要关注最新的LLVM-18.1.2 版本中的崩溃，并尝试将相同的 PoC 应用于其他较低版本。所有已确认的漏洞均已上报至社区，其中一个已被修复，但仍有数百个崩溃待分析。

最终，有8个漏洞被分配了CVE编号，另一个问题仍在处理中。每个漏洞都与LLVM的某个组件相关，表6列出了相关工具，包括bugpoint、opt、llc、clang-repl、lli、clang-import-test 等。表中列出的每个工具都有其特定功能，例如：bugpoint通过简化有缺陷的位代码文件来帮助定位漏洞；opt 用于优化 LLVM 中间表示（IR）。由于这些工具都属于 LLVM 框架，并共享多个关键组件，它们的功能和代码之间存在一定的耦合关系。

表6 确认的漏洞细节和相关工具

在本文中，作者研究了当前编译器选项模糊测试方法中普遍存在的假阴性问题，具体表现为：错误结果中的崩溃被错误消息掩盖，以及成功结果中的崩溃被强制标准输出信息隐藏。为解决这两类假阴性问题，设计了选项修正模块和选项修剪模块，以增强现有的黑盒模糊测试框架。这两种方法均利用了LLM的智能语义理解能力。在受控且一致的计算环境与时间约束下，评估结果表明，所提出的方法显著降低了假阴性率，提升了崩溃检测性能，并发现了额外的唯一崩溃。

Beyond REST：一种用于全面API漏洞模糊测试的工具APIF

SELECTFUZZ:采用选择性路径探索的高效定向模糊测试

Towards Generic DBMS Fuzzing：面向通用数据库的模糊测试

阅读原文

跳转微信打开

在现代软件开发中，API发挥着至关重要的作用，它们促进了平台间的互操作性并作为数据传输的通道。API模糊测试（API fuzzing）已经成为探索Web应用程序、云服务和物联网（IoT）系统中的错误和漏洞的重要方法。其有效性高度依赖于参数结构分析和模糊请求生成。然而，现有方法更多地集中在RESTful API上，缺乏对其他协议的普遍适用性。此外，测试有效负载和测试效率的不足限制了这些方法在现实场景中的大规模应用。本文介绍了APIF，一种新型的API模糊测试框架，包含了三种创新设计。首先，APIF采用树形结构模型来解析和变异不同API协议中的参数，从而突破了现有研究仅适用于RESTful API的局限性，拓宽了其适用范围。其次，APIF使用递归解码器处理API参数中的复杂编码，增加了模糊测试的有效性。第三，APIF结合测试优先级计算算法和参数独立性分析算法，提高了模糊测试的效率，使得该方法能够广泛应用于现实中的大规模API漏洞模糊测试。论文在7个开源项目中通过412个API对APIF进行了与现有最先进模糊测试工具的比较。结果表明，APIF在精度、召回率和效率方面具有显著优势。此外，在实际的API漏洞探索中，APIF在60个API项目中发现了188个漏洞，其中26个漏洞已被软件维护者确认。

2.1  现代服务中的API

Web服务API

传统的Web应用程序通常使用GET/POST方法来获取用户输入的数据，其中：1）GET请求用于加载网页或获取资源；2）POST方法提交表单数据，如用户登录凭据或支付信息。在更先进的应用场景中，WebSocket API提供了客户端和服务器之间的实时双向通信，非常适合聊天应用或实时更新。此外，GraphQL API提供了一种更高效、更灵活的查询和操作数据的方式，允许客户端精确指定所需的数据。通过探索这些不同的API，开发者可以识别并解决更广泛的漏洞问题，如注入攻击、会话劫持或Web应用中的数据过度/不足获取问题。

云服务API

3.1  API参数结构解析

Fuzzer 首先需要理解 API 的参数结构，才能对不同的 API 参数进行变异测试。参数解析的过程包括两个问题：

通用性：现有的研究仅适用于 RESTful API，无法解决第 2.1 节中提到的其他场景，包括 Web 应用中的 SOAP 和 GraphQL API、云应用中的 gRPC，以及物联网系统中的 MQTT 等 API 类型。不同风格和协议的 API 参数结构具有相似性（图 2），这使得论文能够抽象出一种统一的表达方法，从而使 RESTful API 的模糊测试技术能够广泛应用于更多场景。

图 2  不同API协议下，包含两个参数'id=12345'和'cmd=getStatus'的查询API请求信息示例

参数编码：另一个挑战是识别 API 中复杂的编码结构和参数关系。这确保了测试向量能够准确地针对特定参数，而不干扰其他参数的功能。例如，常见的 API 将参数封装在 HTTP 请求体中，使用 JSON、XML 等格式，以及包含嵌套编码的数组类型对象作为参数值。如列表1所示，pfile 参数的值采用 base64 编码，而 info 参数包含 XML 结构化数据。如果没有正确的编码识别和参数解析，盲目修改消息内容进行模糊测试会导致 API 响应中的格式错误，从而妨碍漏洞的发现。

3.2  API参数结构解析

在同一应用程序中按合理顺序测试API非常关键。API参数往往彼此依赖，一个API的响应数据中的值字符串可能是另一个API中有效的请求参数值。如果直接注入数据而不考虑这些依赖关系，可能导致没有意义的结果，并生成大量无效的测试请求，从而影响模糊测试的效率。此外，在一些大型应用中，为了在有限的时间内完成测试，必须计算这些API的优先级，以提高测试过程的效率。

API安全测试通常面临大量的API及其相关的API调用依赖路径。这通常需要在单个API或特定API调用路径上进行大量有效负载注入尝试，导致安全测试结果需要较长时间才能收敛。在会话生命周期有限的情况下，这一问题尤为突出，可能在会话过期前只能完成有限数量的路径测试。通过评估测试优先级，论文可以在给定时间内优先测试那些具有更高漏洞概率的API和API调用路径。

API参数模糊测试是检测API漏洞的关键方法，因为API参数中的任何位置都可能触发漏洞。通常，模糊测试工具在每次API请求中只更改一个参数，这会导致大量的测试请求，从而降低了模糊测试的效率。如果论文能够识别参数之间的相互依赖关系，就可以在一次请求中同时测试多个参数，从而提高模糊测试的效率。列表2显示了一个论坛发帖的API请求。提交时，系统会检查给定的分类值是否已存在，如果未找到则返回错误消息。在单次请求中同时测试category和title参数的模糊测试工具会发现，title的测试向量无效。因此，它们需要两个单独的请求来验证这两个参数。然而，由于title和authorName是独立的，模糊测试工具可以在一个请求中同时对这两个参数进行变异。

论文的设计目标是创建一个实用的API漏洞模糊测试框架，具有更强的通用性、有效性和效率。该框架能够广泛适用于各种API类型，解决复杂参数编码、顺序约束和参数约束等挑战，确保测试向量的有效注入。此外，它能够根据漏洞发生的可能性优先选择测试目标，并同时在单个请求中变异多个参数，最小化计算和网络I/O资源的消耗，从而在大规模批量API模糊测试的实际场景中提供高效性。

基于这些设计目标，论文提出了APIF，一个全面的黑盒API漏洞模糊测试框架。它通过三种方式增强了模糊测试过程。首先，它解码编码的API参数值，并将其解析为统一的基于树的结构。其次，它计算漏洞的发生概率，并识别API之间的依赖关系，以创建合理的测试顺序。第三，它检查API参数之间的相互关系，以便在单个请求中同时注入多个测试向量。这些改进来自现有API模糊测试工作的不足。整个过程的结构如图3所示。

图 3 APIF流程概述图

5.1  API获取

该过程首先在客户端部署一个知名的代理服务器MitmProxy，充当中间人，拦截API通信数据。拦截的消息提供了API结构和参数的相关信息，为在APIF框架内进行进一步分析和测试奠定基础。

5.2  API参数解析

数据集

为了验证论文的研究，论文选择了4个在API模糊测试方法中广泛使用的API漏洞沙箱和3个真实世界的API项目作为模糊测试目标。该数据集不仅涵盖了API漏洞的全面性，还提供了在真实环境中的实用性。API漏洞沙箱包括：

1) crAPI：一个旨在帮助测试人员了解关键API安全风险的项目，设计上容易被攻击，为API模糊测试工具提供了一个实际的测试平台。

2) vAPI：另一个API漏洞平台，模拟了OWASP API安全Top10。

3) APISandbox：提供更广泛的API攻击场景，包括4A认证系统下的问题、基于GraphQL的论坛、经典API漏洞、WSDL泄漏和未经授权的服务器访问。

4) VAmPI：一个由Flask创建的漏洞API集合，包含来自OWASP API安全Top10的漏洞，旨在评估工具在检测API安全问题方面的效率。

对于这些API漏洞沙箱，论文从项目文档中获取了漏洞API和正常API，分别作为正负样本的标签。为了衡量APIF在真实世界API应用中的表现，论文测试了三个开源项目：Spree 、GitLab-CE和SilverStripe，这些项目在真实商业环境中广泛使用。论文从这三个项目过去三年的官方安全更新中获取了漏洞，作为数据集中的正样本。最终的数据集涵盖了7个项目，共有412个API和112个安全漏洞。这些漏洞的类型也已按表1所示进行分类。

模糊测试工具

为了验证论文的研究，论文将APIF与三种最先进的API模糊测试工具进行了比较：

1) RESTler：第一个有状态的RESTful API模糊测试工具，旨在通过REST API自动测试服务中的错误。后来，研究人员改进了该工具用于检测安全漏洞，它被认为是API漏洞模糊测试领域的代表性研究成果。

2) Fuzzapi：GitHub上最受欢迎的API漏洞模糊测试工具，允许安全专家通过进行各种攻击载荷的模糊测试来发现API中的漏洞，并广泛应用于实际的漏洞测试场景。

3) OpenAPI-Fuzzer：另一个在业界广泛使用的开源API漏洞模糊测试工具，已经发现了多个公共系统（如Kubernetes、Vault和Gitea）中的API漏洞。

4) APIF-A：基于该APIF框架的完整技术实现，使用Golang开发。它包括API参数树结构解析、漏洞概率计算以及基于参数相互依赖分析的并发测试。

5) APIF-B：论文提出的理论框架的部分实现。与APIF-A不同，它不进行漏洞概率计算和独立性分析。每个请求仅进行单次突变。

论文对数据集中的所有目标API进行了漏洞测试。图6a展示了每个工具报告的漏洞数量。通过与数据集中的结果进行比较，图6b显示了实际的API漏洞数量。每个工具识别的详细漏洞列在表1中。

图 6 每个模糊测试工具发现的漏洞数量

每个工具的详细指标，包括总测试时间、达到50%和90% API覆盖率的时间、网络I/O次数、网络流量和漏洞数量，如表2所示。论文从多个角度比较了不同工具的实验结果：有效性、效率和通用性。论文还进行了消融测试，并评估了在实际场景中漏洞检测的有效性。

表 1 对于每一个模糊测试工具的真阳性结果

表 2 指标和对比结果

实验一：有效性比较

表2显示，APIF-A和APIF-B在漏洞检测的召回率和精确度方面优于其他工具。除了真实API通信通常包含更多信息外，许多参数只有经过递归解码和编码后才能有效测试。在使用一致的测试载荷库的情况下，这表明论文的API参数解码和树结构突变显著提升了漏洞测试的覆盖率，从而发现了更多潜在的问题。

实验二：效率比较

虽然APIF-A和APIF-B产生了相似的漏洞检测结果，但APIF-A节省了58.9%的测试时间，并显著减少了网络I/O请求和网络流量的消耗。这表明论文在测试向量生成阶段采用的API参数独立性分析算法有效地减少了测试次数并提升了整体测试效率。参数的并发测试导致APIF-A比APIF-B少识别了2个漏洞，表明该算法的准确性仍需进一步优化。

此外，根据图6b中APIF-A的漏洞发现曲线，论文可以观察到，APIF-A在测试时间的前半部分报告了76.4%的漏洞检测结果。APIF-A数据曲线的下降斜率表明，测试优先级计算算法有效地优先考虑了高风险API。在实际的大规模应用测试中，普遍存在在有限的时间内发现尽可能多的安全漏洞的目标。这一要求为在大规模实际应用中部署APIF的可行性提供了有力的支持。

实验三：可推广性比较

论文观察到，SilverStripe项目包含四个GraphQL API漏洞：CVE-2023-44401、CVE-2023-40180、CVE-2023-28104和CVE-2021-28661。如前所述，现有的API漏洞研究已针对RESTful API进行了优化，但未考虑其他类型的API。因此，工具RESTler、Fuzzapi和OpenAPI-Fuzzer未能识别这四个漏洞。同时，APIF-A和APIF-B成功识别了其中的两个漏洞，CVE-2023-28104和CVE-2023-40180。触发这些漏洞需要在插入测试向量之前进一步解码GraphQL消息。论文的APIF框架的递归解码器和树结构变异完成了这一任务，表明APIF的理论方法在不同API协议中都有效，具有更强的可推广性。

实验四：消融实验

为了研究API参数独立性分析和优先级计算策略如何提升APIF的效率，论文对这两个主要组件进行了消融研究。论文实现了APIF的不同变体：1) APIF-A，启用了参数独立性分析和优先级计算，2) APIF-B，移除了参数独立性分析和优先级计算，3) APIFWith-Priority，移除了API参数独立性分析的实现，4) APIF-With-Independence，移除了优先级计算的实现。结果如图7所示。如同之前的研究，测试有效载荷集使用了Seclists，四个测试使用了相同的API通信数据。

在图7a中，与未优化的APIF-B相比，APIF-WithPriority在相对较短的时间内能够发现更多的漏洞，并且不会影响漏洞检测的有效性，同时总体模糊测试持续时间几乎保持不变。这是因为参数优先级分析主要优化了测试顺序。在图7b中，APIF-WithIndependence的曲线显著缩短了整体模糊测试的持续时间，大大提高了效率。这个改进是由于在单个请求中并行插入多个有效负载，使得在给定时间内可以完成更多的测试用例。然而，由于在某些情况下对API参数独立性的判断不准确，检测到的漏洞数量略有下降。这表明参数独立性分析方法仍有进一步优化的空间。

APIF采用被动流量分析来解析API的参数结构。然而，在上述实验过程中，其他工具解析了OpenAPI规范（OAS）文件。为了确保实验结果的有效性，论文为数据集中每个API生成了统一的OAS文件，确保对照组工具不会因为缺少API文档而未能发现漏洞。

在API参数解析中，流量分析和OAS解析是互补的方法，各有优缺点。流量分析擅长捕捉广泛的API上下文，并适用于缺少OAS文件的API，适用各种API类型。其缺点是需要一个中间人服务来拦截API流量。OAS解析则因其简便性而脱颖而出，不需要流量拦截，并且非常适合RESTful API。然而，当OAS文档不可用时，其效果有限，必须手动生成OAS文档。

对于在线服务API，某些功能需要用户认证。例如，一个典型场景可能允许普通用户使用GET方法访问信息，但只有管理员才能使用PUT方法修改信息。为了提高测试覆盖率，API模糊测试器需要理解不同API的认证机制。

在论文的实验中，论文为测试工具和被测应用配置了有效的认证会话，使得模糊测试工具能够访问需要授权的内容。在API漏洞模糊测试中，未能获得API认证信息会显著影响API测试覆盖率。因此，论文为APIF开发了一个认证模块，能够根据预定义的配置在测试请求中携带各种认证信息。用户可以通过配置文件向APIF提交其API访问凭证。一旦APIF识别到认证请求，它将自动携带这些凭证进行后续测试。然而，在实际场景中，并非所有目标应用都支持长期有效的认证会话。在这种情况下，测试工具只能使用它们获得的短期会话执行限时的安全测试。

在进行参数优先级计算之前，论文使用历史CVE漏洞作为数据集，并基于TCL模糊测试验证了相关指标。借鉴论文在API漏洞挖掘领域的经验以及黑盒API安全测试场景的实际特点，论文最终选择了安全测试场景中最具代表性的三个特征维度来计算优先级。通过实验，论文成功地证明了这一改进可以提高基于参数注入、参数修改和参数删除的API漏洞模糊测试效率，从而推动更多后续研究的开展。

然而，API漏洞还包括许多其他类别，例如逻辑漏洞。由于这类漏洞通常需要更为复杂且高度案例化的测试方法，因此本文并未涉及这类漏洞的效率优化方法。在未来的工作中，论文将进一步优化针对不同类型漏洞的优先级引导方法。

本文介绍了一个API漏洞模糊测试框架。论文创新性地采用了树状结构进行API参数的结构分析，有效解决了复杂编码问题，并实现了更深入的API漏洞发现，同时提升了框架的泛化能力，以应对实际批量测试场景中各种类型的API。随后，论文通过计算单个API中漏洞的可能性来进行优先级排序，并分析每个API中的参数独立性，从而优化了API漏洞测试效率。这使得论文能够在单个请求中嵌入多个测试向量，从而显著减少了测试数量，提高了测试效率。

论文的实验结果验证了框架的有效性，显示出其在效率和发现更多漏洞的能力方面，相较于现有的API测试技术具有明显优势。论文将该框架应用于实际漏洞模糊测试，发现了188个BUG和26个漏洞，其中包括6个CVE和12个CNVD，涵盖60个开源API项目。总体而言，论文的方法可以作为改进API漏洞模糊测试技术的一个实际方向。

未来的工作将重点通过引入与漏洞相关的其他因素来完善漏洞可能性评估，并探索这些因素之间的相互关系，以优化论文的评估方法。此外，论文将进一步改进参数独立性分析，以实现更精确和有效的结果。这些改进将进一步提升黑盒API模糊测试的效率。

SELECTFUZZ:采用选择性路径探索的高效定向模糊测试

Towards Generic DBMS Fuzzing：面向通用数据库的模糊测试

mGPTFuzz：大型语言模型辅助Matter物联网设备模糊测试

阅读原文

跳转微信打开

定向灰盒模糊器专门用于测试特定的目标代码。它们已被应用于许多安全应用程序，例如再现已知的崩溃和检测由不完善补丁引起的漏洞。然而，现有的有向模糊器倾向于发现新代码（能够提高代码覆盖率）的输入，而不管新发现的代码是否与目标代码相关。因此，模糊器将探索许多不相关的代码，从而导致测试效率低。

当前的定向模糊测试所面对的一个主要的问题就是会耗费大量的资源来探索一些与目标代码“无关”的代码区域。而现在提升定向模糊测试的方向主要有两个：

（1）通过符号执行或污点追踪等方式获得高质量输入

（2）识别出可以反馈给fuzzer的interesting的输入（哪些输入是值得继续探索的）

总的来说，主要的问题就是如何识别或者说如何衡量一个输入它是否是对fuzz有意义的。以前的定向模糊测试通过两种方式来识别输入是否有趣：

（1）基于序列的输入优先次序：例如在AFLGo中提出的一种用于测算块间距离衡量标准：是在对目标程序生成的CFG中里面采用迪杰斯特拉算法计算两个基本块间的距离，而用于输入序列排序的输入距离就是到目标访问块之间所有基本块的平均距离。但是采用这样的衡量标准并不能提升模糊测试的效率，也无法保证测试用例的有效性。

（2）输入可达性分析：当前在这个方向采取的提升措施主要是深度学习和路径裁剪。使用深度学习的方法即是通过训练一个深度学习模型来提前判断和丢弃那些不可达的输入。使用路径裁剪的方法即是在变量定义语句和分支语句上的检查点上插入断言以确保满足前提条，并终止了永远不会到达目标的分支上的执行。但是这种方法会浪费大量的资源在一些可以到达但是与目标无关的代码测试上。

这里对于前文提到的“有关”与“无关”代码用一个简单的例子来进行简要的说明。考虑图1中的这段简单的代码：

图 1  一个简单的例子

在这个例子中，只有第 14-15 行的代码决定了执行是否能到达目标。如果考虑控制流条件，大量可达代码（例如第 2-10行的代码）都可以认为是与到达目标位置无关的，因为无论路径如何，执行总是可以到达第 11 行。此外，即使第 11-13 行的一些代码与目标有间接的控制流依赖（即，它们影响第 14-15 行的条件变量），但对这些代码进行探索并不能带来显著收益，反而会带来额外开销，所以也将其视为与到达目标位置无关的代码。

尽管如此，我们不能完全排除模糊测试范围中所有与到达目标无关的代码。例如，第 5 行的执行不会影响执行是否能到达目标，但会改变目标中使用的变量（例如x）的值。因此，我们将这些可能会影响漏洞触发的数据相关的代码也视为相关代码。

具体来说，根据这个例子可以构造出这样一个CFG（控制流图），如图2所示：

图 2  简单例子的CFG

现有工具的低效主要源于它们在模糊测试过程中探索了大量无关代码，导致生成的输入队列中大部分是无关输入，从而浪费了计算资源。例如，假设程序从一个初始输入种子开始执行，路径为 a→c→e→h。模糊测试工具从种子生成新输入，其中一部分输入探索了相关代码（如代码块f或b），但其余输入仅发现无关代码。这些无关输入不会推动目标代码的触达或漏洞的触发，因为它们在路径的某些点（如 e）与目标偏离，并且不会影响目标代码的关键状态变量（如 x 或 z）现有工具（如 AFLGo 和 Beacon）在分配能量时无法有效区分相关输入和无关输入。例如，AFLGo 工具虽然会根据输入到目标的距离为无关输入分配较少能量，但由于输入队列中无关输入占比高，总能量分配仍然较大。而 Beacon 工具虽然通过仅包含发现可达代码的输入来减少无关输入，但仍会错误优先处理那些探索无关但可达代码的输入。

总结来说，现有定向模糊测试工具倾向于优先变异无关输入并探索无关代码，从而显著降低了到达目标代码或触发漏洞的效率。

为了解决前面提到的定向模糊测试在与目标无关的代码区域中进行测试而浪费资源的问题，并提高测试效率，本文提出来SELECTFUZZ。SELECTFUZZ的架构如图3所示：

1．距离计算

（Distance computation）

图 4 块间距离的计算算法

该算法为基本块设置了三个状态（status）：

0：初始化

1：正在计算

2：完成计算

其他的变量含义如下：

T:目标代码的位置

Pb:到达的可能性，展示了从基本块b到达目标T的可能性（cal_prob），然后将这个Pb的倒数作为某个基本块到目标位置的距离（cal_dist）

b:基本块

dist：所有基本块到T的距离集合

Prob：所有基本块到T的概率集合

该算法的核心逻辑其实比较简单，其流程主要如下：

（1）初始化：构建程序的过程间控制流图（ICFG）。初始化所有基本块的状态为 0（未计算状态），并将它们的到达概率 prob[b] 设置为 0。

（2）遍历基本块：对所有基本块 b，调用 cal_dist(b) 函数，计算每个基本块到目标代码位置的距离，并将结果存储到 dist[b] 中。

（3）计算距离 (cal_dist)：首先调用 cal_prob(b) 函数，计算基本块 b 的到达概率 Pb。如果 Pb 为 0，返回无穷大（表示不可到达目标）。否则，将距离设置为到达概率的倒数，即 1 / Pb。

（4）计算到达概率 (cal_prob)：如果基本块 b 的状态为 2，直接返回已计算的到达概率。如果基本块 b 的状态为 1，说明存在循环依赖，返回无穷大。如果基本块 b 是目标代码，直接将到达概率设置为 1（100%）。如果基本块 b 不是目标代码，递归计算其所有后继块的到达概率，并取平均值作为 b 的到达概率。

整个算法的核心是这个cal_prob：如果这个基本块b就在目标代码T里，那这个Pb就被设为100%，否则就递归地从这个b的后继块中计算这个可能性，这个Pb就是所有这些后继块可能性的平均值。

在这个算法中，没有考虑条件表达式的复杂性，作者假设条件表达式的每个分支都可以以同样的概率到达。这种简化是必需的，因为真实概率取决于逻辑表达式和相应的输入。对于这个真实概率，可以利用符号执行之类的技术来近似估计，但是由于符号执行也需要输入的实际概率分布来估测这个真实概率，所以作者将这个问题作为未来改进方向。

另外，在真实的项目中存在大量的循环和递归，这里的处理方式是将循环只进行一次Pb计算。而对于跨函数的距离计算，本文将被call函数（callee）所属的基本块作为调用call所属的基本块的后继，从而可以按照算法中的递归逻辑进行距离计算。

输入距离（Input Distance）：

2．选择性路径探索

（Selective Path Exploration）

SELECTFUZZ是基于AFLGo改进的一个定向模糊器。它使用2100行C++代码来实现了其功能原型。其中大约1,400行用于距离测量，约700行用于选择性插桩。距离测量和编译时插桩都实现为编译器的优化通道。SELECTFUZZ支持分析使用LLVM字节码的应用程序。下面介绍一些较为重要的细节。

调用流程图（Call Graph）：SELECTFUZZ通过 Andersen 的点对分析（points-to analysis）推断间接调用中的目标函数。此外，它通过基于参数类型的剪枝和基于地址取用的剪枝优化了不精确的调用图，这些优化可以减少 70% 的调用边数，同时保留正确的调用边。由于当前实现仅支持 C 程序，作者通过支持多态性特性将其扩展到 C++ 程序。通过分析接收者类类型，我们推断方法调用（例如 Obj.func()）的目标函数，并进一步分析多态性，找到正确类中的目标函数。

过程间数据流分析（Inter-procedural Data-flow Analysis）：使用了backward inter-procedural data-flow analysis。首先识别出目标位置上的关键变量，并找到影响这些变量的代码。为了支持跨过程分析，SELECTFUZZ 会分析每个调用点（call site）的被调用函数（callee function），并识别关键变量依赖的数据的参数/参数变量（arguments/parameters）。接着，它分析被调用函数内的数据流关系，以推断其返回值是否与关键变量存在数据依赖关系。最后，SELECTFUZZ 将被调用函数的返回值传播到正确的调用点，并以上下文敏感的方式进行处理。

别名分析（Alias Analysis）：SELECTFUZZ的数据流分析结合了保守点对分析（conservative points-to analysis），以处理指针别名问题。由于使用了保守的点对分析，SELECTFUZZ 在识别别名时会出现假阳性，从而也可能导致错误识别数据依赖代码。例如，它可能错误地判断两个指针指向相同的内存位置，并认为它们存在数据依赖。提升点对分析的精度是当前一个的挑战，作者会在后面部分讨论假阳性的问题。

执行超时（Execution Timeout）：在SELECTFUZZ中，fuzzer对于输入执行的超时设计还是在超过设定的时限后会减少分配给对应输入的资源，但是并不会直接将超时的输入丢弃，因为他们可能虽然超时了，但是仍能探索到新的相关代码。

在文中，作者提出了对其开发的SELECTFUZZ总结了以下几点仍需改进的地方并提出了自己的改进设想：

（1）SELECTFUZZ 在识别相关代码时可能高估范围，因为调用关系的近似处理、保守的数据流分析以及对目标代码中所有变量都视为关键变量的假设可能导致误判，例如仅数组和索引才是触发数组越界漏洞的关键变量。尽管现有设计已显著减少了探索范围，但更先进的静态分析技术（如结构敏感的指针分析）可以进一步优化。

（2）SELECTFUZZ 依赖随机变异生成输入，在解决复杂路径约束时效果有限，这也是导致部分崩溃无法触发的原因之一。未来可以结合污点跟踪、符号执行或结构感知变异等技术提升其能力。

（3）同时，SELECTFUZZ 目前会探索所有可达路径，但其中并非所有路径都存在并可以触发漏洞，这可能导致在触发漏洞时消耗额外时间。为解决这一问题，可通过引入更多漏洞相关信息（如崩溃转储）来优化目标路径的选择。

本文提出了SELECTFUZZ，这是一种创新的定向模糊测试工具，通过选择性地探索相关程序路径，提升崩溃复现和漏洞检测的效率。SELECTFUZZ专注于识别并插桩与触发指定漏洞相关的代码，同时引入了一种新颖的距离度量方法，用于精准评估路径和输入的到达概率。评估结果显示，SELECTFUZZ相比AFLGo实现了最高46.41倍的速度提升，并在Google Fuzzer测试套件中的8个崩溃复现任务中表现最佳。此外，SELECTFUZZ能够与路径修剪等现有技术互为补充，进一步增强其实用性。通过SELECTFUZZ，作者发现并报告了14个真实程序中的新漏洞，其中已有11个被官方修复。

Towards Generic DBMS Fuzzing：面向通用数据库的模糊测试

mGPTFuzz：大型语言模型辅助Matter物联网设备模糊测试

Halo：通过可能不变量推断的反例引导定向模糊测试

阅读原文

跳转微信打开

在现代网络空间中，数据库管理系统（DBMSs）至关重要，其涵盖关系型（SQL）和非关系型（NoSQL）数据库，以满足多样化应用需求。关系型 DBMSs 已被广泛研究和应用数十年，而非关系型 DBMSs 因在处理大规模非结构化数据方面的灵活性和性能优势，近年来也得到广泛采用。鉴于这些系统的普遍性和关键性，强化其安全性与稳健性势在必行。

模糊测试（Fuzzing）作为一种自动化软件测试方法，在发现 DBMSs 缺陷方面颇具成效。然而，针对非关系型 DBMSs 的模糊测试工作相对薄弱。尽管关系型 DBMSs 的模糊测试框架和研究成果丰硕，但非关系型 DBMSs 尚未得到同等程度的审视，现有通用模糊测试框架应用于非关系型 DBMSs 时效果不佳，缺乏能同时有效测试关系型和非关系型 DBMSs 的解决方案。

面对非关系型数据库目前没有一个通用的模糊测试框架。本文深刻分析了对于非关系型数据库使用模糊测试存在的是哪个复杂挑战。

(1)非关系型数据库接口多样性致使难以构建通用框架，在保障测试用例质量的同时兼顾对不同接口的适应性。

(2)非关系型数据库对语义的依赖方式多样，且语义随上下文变化明显。针对不同的非关系型数据库，对生成的中间表示（IR）进行语义约束十分困难。

(3)随机变异易产生松散数据依赖，触发低效测试行为，而数据依赖在有效模糊测试中起着关键作用。

为应对上述挑战，构建针对通过非关系型数据库的专用模糊测试工具，本文提出语义抽象、上下文敏感约束解析和依赖引导变异三项解决方案，并将其整合到端到端模糊测试框架BuzzBee中。

该框架能够有效测试多种类型的 DBMSs，在八个不同数据模型的 DBMSs 中成功发现 40 个漏洞，其中 25 个已修复且 4 个被分配新的 CVE 编号。在评估中，BuzzBee 在代码覆盖率方面相比现有最佳通用模糊器提升高达 177%，在非关系型 DBMSs 测试中发现的漏洞数量比次优模糊器多 30 倍。在关系型 DBMSs 测试中也能取得与专业 SQL 模糊器相当的结果。

图 1  BuzzBee流程图

工具整体的测试流程如图1所示。用户输入的文件包括Corpus和Input-Specs两个部分。然后工具根据Input-Specs中的g4语法文件和初始种子用例使用 ANTLR4 语法对输入的测试用例进行解析，基于语法规则构建抽象语法树（AST）。同时，利用注释文件中的信息对AST 节点进行标注。注释文件通过语法标签将语法规则中的元素与语义信息相关联，用户可以为不同的语法结构指定如定义（Define）、使用（Use）、失效（Invalidate）等基本语义操作以及相关的约束信息（如数据类型等）。这些标注信息为后续生成中间表示（IR）提供了语义基础。然后生成语法结构完整的IR，并放入工具设计的注释系统（Annotation system）中，在注释系统中，工具根据用户提供的Input-Specs的语义json文件和工具设计的上下文查询语言（CQL）或用户自定义的操作（Custom Resolver）对IR实现紧凑的语义数据依赖。根据引导性变异器实现完全保证语法正确并尽量保证语义正确（在先前数据库模糊测试工具SQUIRREL中已经解释实现完全语义正确是np问题）的测试用例。然后语义检查系统对测试用进行最后的语义检查，有语义错误的尽量修改，否则丢弃。最后通过整个流程的IR会被放入模糊测试器进行测试。然后根据feedback对初始种子进行更新，同时对引导变异器的原则进行自适应调整。接下来是对每个部件的详细介绍。

1．输入文件

如图2，以对redis键值对数据库为例，示例选取了仅仅包括HSET和HINCRBY两个key的初始种子用例。初始种子用例都是语法语义正确的可被数据库接受的输入。这些初始的测试用例都有用户提供。后续经过每轮模糊测试都都会自动更新。

图 2 初始种子图例

图3所示的是语法语义的约束文件。左边的是语法约束文件。其中示例定义了HSET的语法规则，并以HSET语法为例做一下详细解释。HSET0定义了顶层规则，表示整个HSET命令的结构。它由HSET1（命令名），HSET3（哈希键），HSET4（字段），HSET5（值）以及HSET6（可能包含多个字段和字段值的组合）组成。其中可以看到在HSET3和HSET4与HSET8后的元素字段后加上了#HSETRule1和#HSETfield1等这样的字段。这是工具需要的语法标签（grammar tag)。这是标记这个语法点的记号，方便用户后续在使用注释系统时对这个记号点的值进行语义的定义。具体的语义注释系统将会在后续章节介绍。这样的语法规则是基于现有工具ANTLR4的定义规则要求的，现有很多开源的常用数据库的这种g4语法规则文件，用户只需按照需求下载后对所需的语义点打上grammar tag并为其写上语义文件即可。

图3右图所展示的是语义语法规则。如语法规则中的HSET3，HSET4和HSET8中分别打了一个grammar tag，其作用是给用户自定义该键值位置语义规则。语义规则由用户使用json文件自定义。包括三个内容action，args和ast_context。其具体含义会在后续内容（构建中间表示和注释系统）中详细介绍。

图 3 语法语义约束文件

2．构建中间表示

构建中间表示IR首先根据用户提供的g4语法文件使用 ANTLR4 语法对输入的测试用例进行解析，基于语法规则构建抽象语法树（AST）。同时，利用注释文件中的信息对 AST 节点进行标注。注释文件通过语法标签将语法规则中的元素与语义信息相关联，用户可以为不同的语法结构指定如定义（Define）、使用（Use）、失效（Invalidate）等基本语义操作以及相关的约束信息（如数据类型等）。这些标注信息为后续生成 IR 提供了语义基础。

定义（Define）：表示数据创建。例如，在图 4c 中，第一个 Redis 命令 HSET 定义了类型为 HSET key 的数据 k1 以及类型为 HSET field of k1 的 k1_field1。类似地，在图 1a 中，PostgreSQL 查询 CREATE TABLE 定义了两个数据：类型为 table 的 t1 和类型为 col_of_t1（表示 t1 的列）的 c1。需要注意的是，这些数据可能存在从属关系，例如 k1_field1 从属于 k1，意味着没有 k1 就不存在 k1_field1。同样，t1 和 c1 也存在这种关系。这种关系可以通过本文的上下文查询语言（CQL）和自定义解析器进行建模，稍后将详细介绍。其基本思想是在数据类型中包含具体的符号名称，例如 k1_field 的类型为 HSET field of k1，其中包含了具体符号名称 k1，表示 k1_field 与 k1 相关联。这时就很容易理解图3右图部分语义规则约束的action的用意了。HSET在redis数据库中是创建命令，所以action为定义。同理对于SQL关系型数据库，键值create也是定义操作，action也会赋值为define。

图 4 不同类别数据库执行语句示例图

使用（Use）：表示对已定义数据的访问和更新操作。例如，图4c 中第 4 行和第 8 行的 HINCRBY 命令使用了由两个 HSET 命令定义的数据 k1、k1_field1、k2 和 k2_field1。使用未定义的数据被视为语义错误。同样，对于redis数据库，HINCRBY命令是对于已经定义的key进行值的加减操作，故其语义action应该设置为use，对于SQL类数据库，例如select语句，其语义aciton也就是use。

失效（Invalidate）：表示对已定义数据的删除操作。一旦数据被失效，就不能再次使用。需要注意的是，数据删除应遵循从属关系。例如，在图 4c 中，如果取消注释第 7 行的 DEL 命令，它将删除 k2。由于k2_field1 与 k2 存在从属关系，k2_field1 也应被删除。同样，在图4a 中，如果删除表 t1，其列 c1 也应被删除。在执行失效操作后，对已失效数据的任何使用都将被视为语义错误。因此，如果取消注释图 1c 中第 7 行的 DEL 命令，第 8 行将会产生两个语义错误，因为 k2 和 k2_field1 都已被失效。同理对于SQL类数据库，例如delete语句，其语义action也应该定义为Invalidate。

3．注释系统

如图6所示，这是一个简单是初始种子和语法语义文件。其中在语法文件中grammar tag以①形式简化。对于③我们可以看到这是HSET操作的key，所以type就是HSET-key。而对于④，是key值得一个具体的field。他的type定义是HSET numeric field of {.lsib(1)@text}。这个表达式的意义需要结合文章提出的CQL上下文查询语言来理解。例如对于图6中的左图第5行HINCRBY语句，假设已经构建好的IR如图5中的抽象IR，最下面一行表示的是这个语句在抽象语法树中的形式。.lsib(1)是指查找该节点的第一个左兄弟节点。是作为导航器。此时就找到了key节点，然后@text表示读取该节点的内容，即读取到了k1。如此原理根据CQL语言解析后，k1_field1的type定义就是HSET numeric field of k1。这是一种简单有效的标记语义的方式。但同时作者也注意到，使用这种简单的硬编码方式对于一些复杂的语义场景是不具有兼容性的。于是作者同时设计了一个用户自定义操作。需要用户自己用C语言实现。例如②，type中的是hset_field_type_resolver。这是一个用户用C语言自定义的操作，其具体操作是首先导航到field的.rlib(1)，读取value的值。如果value的值是数字类型则返回HSET numeric field of {.lsib(1)@text}，否则返回HSET field of {.lsib(1)@text}。根据上文描述，我们已经知道{.lsib(1)@text}表示读取左边第一个节点的值。接下来看图6中的第一行和第二行代码。HSET kl k1_field1 “Hello”，对于k1_field1，读取value值，及Hello，非数字，返回，HSET field of {.lsib(1)@text}。所以k1_field1的type是HSET field of k1。同理可得k2_field1的type是HSET numeric field of k2。后续的引导性变异过程中进行节点替换时，如果将k1_field1和k2_field1相互替换将导致语义错误，因为二者的类型不一样。这样做的意义是在避免这类语义错误。

在每次模糊测试的迭代过程中，PromptFuzz 会探索种子库并更新这些种子程序的质量。利用库 API 的能量反馈和种子质量，PromptFuzz 应用算法1来选择在下一次迭代中使用的新API组合。如果当前迭代中的种子程序不足，PromptFuzz 进入预热阶段（算法1的第3-7行），随机选择高能量API函数以探索之前未发现的库使用。在变异阶段（算法1的第9-23行），PromptFuzz 使用种子程序关键路径上的API调用序列作为变异的枢纽，丢弃那些不与其他API调用交互的调用。将变异集中在枢纽上，使PromptFuzz能够探索复杂的API使用。最后，PromptFuzz 使用新的API组合构建下一次程序生成的提示。

图 6 语义解析示例图

4．引导性变异器

引导性变异器也是这篇文章的一个重要设计组件之一。其目的是通过变异测试用例来探索DBMS 的更多行为并发现潜在漏洞，遵循依赖引导变异原则，以数据依赖为指导优先选择能形成新数据依赖的变异操作，同时保持语法正确性。由于在变异之前已经实现了构建语法正确的抽象语法树（AST），在变异过程中为了保证测试用例的语法语义正确，作者主要使用三种变异手段，包括节点替换、插入和删除。

具体实现过程中首先需要从输入与信息获取，从语义分析器获取提升后的 IR 程序作为输入，获取其中的符号和作用域信息等。接下来从三种变异操作中选取来对测试用例进行变异。节点替换是指优先选择与当前节点已定义且未失效的符号相关的节点进行替换，这些符号能与测试用例中的现有符号形成依赖关系，触发更深层次的程序状态。比如在处理数据库操作命令时，若要替换某个节点，会从 IR 池中选择包含相关使用或失效操作的节点。节点插入遵循与节点替换类似的逻辑，找到合适的节点进行插入以形成新的数据依赖。节点删除就是随机选择一些语句的关键字进行删除，当然，为了保证语义的正确性，有相关依赖的语句也要同时删除。还是以redis数据库为例。对于节点的替换，以初始命令HSET k1 k1_field1 1为例，可能的变异操作包括将HSET节点替换为HINCRBY节点，利用之前创建的数据形成新的数据依赖，触发增加数据的操作；同样对于节点的插入，还是假设现在有HSET k1 k1_field1 1，接下来需要再插入一条命令，由于有语义约束，且工具希望生成的测试用例有紧密的数据依赖，工具希望插入的语句和这个hest定义语句有语义依赖，就只能从Use和Invalidate两个操作中选取一个来对k1进行操作。例如可从IR池中选择的操作包括HINRBY或DEL。至于具体工具会选择哪个操作，会在后续权重分配部分详细介绍。对于节点删除部分，作者目前并未提出一些有指导性的删除策略，就是对一些节点进行随机删除，如果破坏了语义信息，后续会有语义检查和语义修复组件，当然删除也需要根据语义依赖进行删除。例如语句HSET k1 k1_field1 value1 k1_field2 value2，假设此时变异器决定对k1_field2节点进行删除，由于value2也是语义依赖k1_field2的，所以value2也将同时被删除。即节点删除后的语句变成HSET k1 k1_field1 value1。

上述介绍的是具体的变异操作，而具体的的变异选择工具遵循行为覆盖优化原则。其原理是根据候选节点是否已存在于测试用例中对其进行优先级排序，为语义动作分配权重，出现次数越多的动作权重越低。这就会指导之前在节点插入部分提到的具体插入哪个语句关键词的问题。例如在图6左上部分第一块，现在要在第4行选择插入的语句。假设HINCRBY和DEL是唯二的选择，而根据行为覆盖优化原则，HINCRBY由于在第5行已经出现，其权重变低，所以工具会选择DEL进行插入（尽管插入后或导致第5行的HINCRBY对一个有已经失效的key进行操作而导致语义错误。这个语义错误会在后续被检查并修复）。这个原则的最终目的是使变异测试用例中不同动作的数量均匀分布，以覆盖更多行为。

总体来说，对于一般的数据库操作，如创建、读取、更新和删除数据的操作序列，变异器会依据数据依赖关系进行优化。若已存在创建数据的操作，会倾向于插入读取或更新该数据的操作，而不是再次创建相同的数据，以更有效地探索数据库行为并发现潜在问题。

5．语义检查系统

语义分析器是根据用户指定的约束来检查抽象语义模型中语义正确性的组件，它通过执行模拟来实现这一目标，该模拟过程包括依赖分析和执行模拟两个阶段。在依赖分析阶段，语义分析器会遍历 IR 程序中的每一个操作，收集每个操作所依赖的上下文，并构建依赖图，然后进行拓扑排序以确定 IR 节点的执行顺序。在执行模拟阶段，语义分析器会按照确定的顺序执行语义操作，对于“定义” 操作，会在当前作用域中定义符号，对于 “使用” 操作，会在作用域树中查找匹配的符号并使用，对于 “失效” 操作，除了执行与 “使用” 操作相同的过程外，还会使符号失效。在这个过程中，语义分析器会评估操作参数中使用的 CQL 查询，并调用自定义解析器来解决特定的值。同时，符号的重新定义、在定义之前使用或在失效之后使用等情况都会被视为语义错误，操作所依赖的上下文包含语义错误时，该操作也会被设置为语义错误。例如，HSET k1 k1_filed1 value1/HMSET k1 k1_filed1 value1。这就是多次定义语义错误。而定义前使用和失效后使用都是例如当前k1值是未定义状态或者已经失效状态后再执行类似于HINCRBY k1 k1_filed1 value1这样类似的Use类的操作。这些都将被视为语义错误来进行处理。

语义分析器会维护符号表和作用域树来跟踪成功执行的操作，并返回所有的符号和作用域信息以及语义错误作为分析结果。最后，语义验证器会在BuzzBee 将测试用例发送到模糊测试器之前，先放入到DBMS系统进行模拟执行，检测语义错误并尝试修复测试用例中的语义错误，例如对于在定义之前使用或在失效之后使用的错误，会寻找其他可用数据来使用，对于重新定义的错误，会尝试用未定义的名称来定义数据，当无法修复错误时，BuzzBee 会放弃这个测试用例。

对于上述提到的整个语义分析，模拟执行和错误纠正流程举一个例子。例如，对于 HSET k1 k1_field1 "Hello" 命令，在语义分析时，首先确定这是一个定义操作（Define），定义了键 k1 及其字段 k1_field1 的值为 "Hello"。此时会检查是否符合定义操作的语义规则，比如键和字段的命名是否合法等。

接着HINCRBY k1 k1_field1 1 命令，这是一个使用（Use）并更新操作，它依赖于前面 HSET 定义的 k1 和 k1_field1。语义分析会检查是否存在对未定义符号的使用，以及操作类型是否与定义的符号类型兼容。在这个例子中，如果 k1_field1 之前被定义为非数值类型（如这里的字符串 "Hello"），那么按照语义规则，HINCRBY 操作在此处就是语义错误的，因为它不能对非数值类型进行自增操作。

这是检测到了这个执行例子存在一个语义错误，语义验证器就会去尝试修改。根据上述提到的修改思路，语义验证器在IR池中找到了例如 HSET k1 k1_field2 1这个语句后，就会用k1_field2去替换之前导致语义出错的k1_field1。这样执行语句将会变为 HINCRBY k1 k1_field2 1。此时满足语义语法规则。当然这只是一个简单的示例，具体现实测试中遇到复杂的情况，语义验证器无法修复的话这个测试用例将会被丢弃。

1．实验设计

硬件环境：在一台运行Ubuntu 22.04.2 LTS 操作系统的机器上进行所有评估，该机器配备两颗AMD EPYC 7452 32 核处理器以及1,024GB RAM。

目标选择：针对三种主流的非关系型数据库（键值、图、文档数据库）和关系型数据库（SQL 数据库）进行评估。具体选取了键值类的redis 和KeyDB、图类的RedisGraph 和AgensGraph、文档类的MongoDB 和ArangoDB、关系型的PostgreSQL 和MySQL。选择依据是其流行程度，并且选择C/C++ 目标是因为当前的模糊测试运行时（AFL++）对其支持最佳。

漏洞挖掘评估：在所选目标的最新发布版本或开发分支上对BuzzBee 进行评估。对 redis、ArangoDB、RedisGraph 和 PostgreSQL 四个目标进行了关于代码覆盖率和漏洞检测能力的综合评估，原因是它们具有较高的模糊测试稳定性且涵盖了所评估的所有四类数据库。同时，将 BuzzBee 与六个先进的模糊测试框架进行比较，包括通用模糊器 AFL++、REDQUEEN、POLYGLOT、Grammarinator 以及专门的 SQL 模糊器 SQUIRREL 和 SQLANCER。在评估过程中，为所有模糊器提供相同的输入（如果需要），并将计算能力限制为一个 CPU 核心。对于漏洞检测评估，将数据库回滚到所有漏洞未修复的版本，每个实验运行24 小时，重复五次，并报告平均结果。

2．实验结果

图 7 对比试验及消融实验结果

项目让每个模糊器运行24 小时并重复五次，报告在此期间它发现的漏洞。图7的左边表格中Property列 “Data” 表示该漏洞需要正确的数据依赖关系才能触发。“Sem” 表示该漏洞不需要数据依赖关系来触发，但触发的测试用例在语义上是正确的。“Syn” 表示该漏洞在语义上不正确但在语法上是正确的。“⊖” 表示该模糊器不支持此数据库管理系统。作者设计的消融实验部分BuzzBee代表功能完善的工具，BuzzBee！g表示没有引导性变异的部分，BuzzBee！gc表示没有引导性变异和上下文敏感约束部分，BuzzBee！gcs表示没有引导性变异，上下文敏感约束部分同时也没有语义抽象部分。

首先看消融实验部分，可以看出，完整的工具找到了最多的bug，而失去引导性变异的工具对于很多data类型的漏洞，及需要强烈数据依赖的漏洞，显得力不从心，但是对于只需要语义正确的sem类型的漏洞还是能够找到。而BuzzBee！gcs工具几乎就不能找到任何类型的漏洞了。但是BuzzBee！gcs 工具找到了一个其他任何消融工具都没有找到的漏洞，对于这个问题作者解释道这个漏洞其实是不符合语义规范的，及不在最开始输入的语义规范定义的json文件里，所以其他的有语义抽象模块的BuzzBee都不能生成这个测试用例。这个漏洞会在后文的bug分析中提到。

接下来看现有工具对比实验测试结果。可以看到对于非关系型数据库，进行测试的AFL++、REDQUEEN、POLYGLOT、Grammarinator 等工具几乎没有找到漏洞，同样对于关系型数据库，专门的 SQL 模糊器SQUIRREL 和 SQLANCER也没有找到漏洞。

然后对比工具的覆盖率，如图7右图，对于非关系性数据库，BuzzBee的覆盖率明显高于通用模糊测试器，而对于关系性数据库，BuzzBee的效果也能几乎达到SQL数据库专用模糊测试器的覆盖率。

3．PromptFuzz组件的有效性Bug分析

图 8 bug示例

作者在文章中列举出了BuzzBee工具在现实数据库中找到的三个漏洞。接下来看每个漏洞的具体分析。

案例 A：RedisGraph 中的断言失败漏洞

漏洞详情：在 RedisGraph 中，执行GRAPH.QUERY g "WITH 1 AS x MATCH (m),(n) WITH * ORDER BY m \SKIP 0 LIMIT 90 WHERE m = 0 RETURN 0" 查询时，服务器（v2.10.8）会触发运行时断言失败，导致崩溃。此漏洞源于处理星型投影（“WITH *” 部分）的函数。

触发条件：触发该漏洞需要满足正确的数据依赖关系。例如，若将查询中的ORDER by m 里的变量 m 更改为未定义变量（如 v0），服务器会返回 “(error) v0 not defined” 且不会崩溃。

发现过程：BuzzBee 通过其注释系统识别出定义的变量 m 和 n，并维护了正确的数据依赖关系，从而成功发现此漏洞。这体现了 BuzzBee 在处理复杂查询和确保数据依赖正确方面的能力，能够有效发现因数据依赖问题导致的漏洞。

案例 B：Redis 中的整数溢出漏洞

漏洞详情：对于测试用例，HMSET k1 k1_field1 1创建了一个哈希集 k1 并存储了一个字段 / 值对，HRANDFIELD k1 -9223372036854770000 with values 命令在处理该特制命令时，HRANDFIELD 命令的处理逻辑存在整数溢出漏洞，导致redis服务器崩溃。

背景与难点：尽管该测试用例结构看似简单，但由于redis中存在大量非依赖关联操作，追溯相关代码后发现此漏洞已在代码库中隐藏至少三年，这使得发现该漏洞变得非常困难。

解决方法与发现过程：BuzzBee 利用依赖引导突变来解决此问题。当测试用例中存在 HMSET 命令时，它会主动搜索能够形成新数据依赖关系的操作。通过这种方式，BuzzBee 成功发现了这个隐藏已久的漏洞，展示了其在处理非依赖关联操作较多的数据库时，挖掘深层次漏洞的能力。

案例 C：Redis 中的断言失败漏洞（使用后失效数据依赖）

漏洞详情：测试用例首先创建一个名为set1 的哈希集并调用 EXPIRE 使其失效，接着 HINCRBYFLOAT set1 k -inf with values 命令在处理过期符号时错误地实现了错误处理程序，使数据库管理系统处于脆弱状态，最后 HRANDFIELD set1 -3 WITHVALUES 命令可导致服务器崩溃。这个漏洞我们可以看出，他先使得这个set1失效，然后又对这个set1进行了Use类的操作。这很明显是一个语义错误的操作语句，这违反了数据依赖规则。这个漏洞也就是BuzzBee！gcs找到并触发的。因为根据语义约束，其他工具不会产生这种语义错误的测试用例。

触发条件：此漏洞需要一种特殊的“失效后使用” 数据依赖关系来触发。

发现过程：为了使用BuzzBee工具复现此漏洞，研究人员手动修改了 EXPIRE 命令的注释从 “Invalidate”（失效）到 “Use”（使用）来测试数据库管理系统对无效化数据的处理情况。基于此发现，未来计划在BuzzBee 中引入新的模式，自动修改某些注释以发现类似部分违反数据依赖规则的漏洞，进一步提升其漏洞发现能力。

4．CVE列表

图9给出了BuzzBee工具找到的漏洞列表，其中包含了包括redis, KeyDB, RedisGraph, AgenmsGraph, MongoDB, ArangDB, PostgreSQL和MySQL等8个数据库的40余个漏洞。在图9中的status栏目，* 表示 BuzzBee 在最新的数据库管理系统（DBMS）中发现了该漏洞，作者报告此漏洞时供应商已经知晓。†表示该漏洞是已知的，但不在最新的 DBMS 中。

在这项工作中，作者明确了在对不同的数据库管理系统（DBMS）接口进行模糊测试时所面临的独特挑战。作者提出了相应的解决方案，并将其整合到一个开源的端到端模糊测试框架——BuzzBee 中。并且该文章对BuzzBee 进行了全面的评估，与最先进的模糊测试工具相比，BuzzBee 实现了高达177% 的代码覆盖率，并且在主流数据库管理系统中发现了40 个实际存在的漏洞，这表明了它的通用性和有效性。

mGPTFuzz：大型语言模型辅助Matter物联网设备模糊测试

Halo：通过可能不变量推断的反例引导定向模糊测试

SEAMFUZZ：灰盒模糊测试的学习种子自适应突变策略

阅读原文

跳转微信打开

要从Matter规范中提取信息，一种直接的方法是手动仔细阅读并绘制所有状态机（FSM）。然而，由于以下原因，作者使用LLM来进行该过程：

图 2  mGPTfuzz的主要架构

从规范中提取与命令和属性相关的信息（Information Extraction）

图 3 查询基础数据类型的提示词

图 4 查询每个集群信息的提示词模板

图 5 大语言模型关于onoff集群的响应

FSM是一个元组 (Q,Σ,Δ,δ)，其中Q表示有限状态集，Σ表示初始状态，Δ表示目标状态，δ表示可以将Σ映射到Δ的命令。给定一个集群，作者对每个命令进行查询，并生成特定于该命令的FSM。之后，所有FSM组合起来形成代表整个集群的综合FSM。

图6显示了用于查询命令（使用命令ID指定）的有用信息以生成FSM的提示模板。在这个过程中：

（1）应用上下文少样本学习，如图6的Shot 1部分所示；

（2）提供了有关基本数据类型的数据类型知识（通过图3中基本数据类型的提取）和与集群相关的派生数据类型（通过图4中的查询1）。这使得LLM能够准确理解思想链过程第二步中的数据范围；

（3）利用思想链提示来确保LLM提取信息的准确性（见图6中的思想链部分）。思维链提示涉及构建提示来指导LLM完成一系列逻辑步骤，类似于人类的思维过程，以达到所需的输出。当简单的问答格式可能无法产生全面的结果时，这种技术在复杂的情况下被证明特别有效。

（4）利用自我一致性检查来增强响应的可靠性。

即使采用设置temperature=0等方法来防止随机性和创造性，仍然存在以下罕见情况：1）LLM 可能会产生格式与Shot 1不一致的响应，2）LLM 在以下情况下伪造信息：提供的集群文本不包含与查询相关的信息。作者将第一个问题归因于输出的复杂性。为了确保 LLM 响应遵循所需的格式，作者在提示末尾添加“所需的输出格式”部分。为了解决第二个问题，作者强调不要编造信息，如图6第一段的最后一句所示。

图 6 生成FSM的提示词模板

通过这些提示设计方法，作者能够有效地获取FSM信息。在为集群内的每个命令生成 FSM后，作者将所有FSM合并为代表该集群的综合FSM。生成了52个 FSM，总共有521 个状态和522个转换。对于52个FSM，状态数在[1, 46]范围内，边数在[1, 50]范围内。

例子：图7显示了生成的 FSM 的一部分，它是通过合并与LevelControl集群内的所有命令相对应的多个FSM来实现的。此示例包含10个状态和13个边。每条边都包含有关状态转换过程的详细信息，包括命令名称以及每个参数的可能值和数据类型。

图 7 LevelControl集群生成的FSM

验证 FSM 的质量：除了使用多个查询进行自我一致性检查之外，作者还手动验证FSM 的质量。首先从522 个转换中随机抽取100个样本。三位作者总共花费了9个小时手动独立检查100个转换中描述的信息的准确性。作者确认所有信息都是准确的。然后作者选择一个集群LevelControl，并检查FSM是否涵盖了规范中描述的所有转换，结果是肯定的。检验表明LLM能够准确提取FSM信息。

模糊器迭代FSM以生成测试输入。使用以下策略：

1．实验设置

2．崩溃发现结果

作者将错误分为两类：（1）崩溃错误，会导致设备崩溃；（2）非崩溃错误，会导致不正确的行为，但不会导致设备崩溃。

表 1 mGPTFuzz 检测到的错误。(1) UT 代表 Unexpected Transition，意思是设备转变到意外状态。 (2) DoS 是指拒绝服务。模糊测试时间主要由设备支持的命令和属性的数量决定。

崩溃错误：

• 设备Nanoleaf Lighting NF080K03-2LS（设备ID = 4）中存在一个崩溃错误，已分配CVE-2023-45955。
• Govee Lighting H61E1（设备ID = 10）存在4个崩溃错误，这些错误都是有状态错误，需要将设备设置为要触发的特定状态。这些错误已分配为CVE-2023-45956。

非崩溃错误：

3．与Baseline方法的对比

4．效率

图 8 测试效率结果，红点代表崩溃错误，绿点代表非崩溃错误

影响：mGPTFuzz仅限于模糊测试Matter设备。然而，考虑到Matter的重要性，付出的努力是值得的。此外，LLM辅助的黑盒模糊测试方法可以推广到其他可用规范的场景，例如Zigbee、Thread 和蓝牙。

阅读原文

跳转微信打开

图 4 基于距离的选择输入直觉

如何选择输入：基于距离的输入选择直觉，作者设计了一种基于距离的输入选择策略，以选择能够推断出更精确不变量的输入。距离度量描述了每个输入与条件边界的接近程度。可以把路径条件视为一个函数f(x),其中是相关x输入字节的向量。使f(x)=0的输入构成了条件的边界。输入到边界的距离可以表示为|f(x)|。因此，应该选择|f(x)|较小的输入用于不变量推断。

RQ1：与最先进的（定向）模糊测试工具相比，Halo是否能够更快速地复现目标漏洞？RQ2：Halo 是否能够有效解决间接输入生成问题？

RQ3：Halo 是否能够在实际中检测到不完整的修复和新漏洞？

1．实验设置

图 6 相比较的模糊测试工具

2．漏洞复现能力RQ1

图 8 Magma基准测试中Halo与定向模糊测试器相比较每个目标的重现时间

图 11 Halo在24小时评估中用于可能的不变性推断、输入生成和模糊测试引擎的时间成本的平均比例

4．效率RQ3

5．消融实验RQ4

2024年软件工程顶会Fuzz论文汇总

SEAMFUZZ：灰盒模糊测试的学习种子自适应突变策略

DeepGo: 预测定向灰盒模糊测试

阅读原文

跳转微信打开