Alleysira's blog
0%

When Fuzzing Meets LLMs Challenges and Opportunities

Posted on

LLM4Fuzz的综述

本文总结了5个使用LLM辅助模糊测试的挑战，回顾了顶会论文并确认了挑战的广泛存在，提出了解决方案并在DBMS进行了评估，说明了推荐方法的有效性

1
2
3
4
5
6
7
@inproceedings{jiang2024fuzzing,
  title={When fuzzing meets llms: Challenges and opportunities},
  author={Jiang, Yu and Liang, Jie and Ma, Fuchen and Chen, Yuanliang and Zhou, Chijin and Shen, Yuheng and Wu, Zhiyong and Fu, Jingzhou and Wang, Mingzhe and Li, Shanshan and others},
  booktitle={Companion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering},
  pages={492--496},
  year={2024}
}

Introduction

LLM的短板：上下文长度、幻觉

导致了测试性能退化、误报率、低测试覆盖和有限的可扩展性

challenges：

  • 生产的输出质量低，不满足驱动程序要求的精度
  • 模型的理解和处理能力限制
  • 在模糊测试过程中难以生成足够多样化的输入
  • 无法保证保持生成输入的有效性
  • 对漏洞检测机制的错误理解阻碍了它们有效识别和解决复杂软件漏洞的能力

CHALLENGES AND OPPORTUNITIES

image-20241006165734039

Driver Synthesis

驱动程序合成方面的已有工作的思路是利用API文档作为Prompt，要求LLM生成API调用序列作为模糊测试驱动程序

由于LLM的幻觉和对不在训练数据中的程序效果差，直接使用LLM进行测试驱动程序生成效果不好

  • 生成的驱动程序容易出错，导致测试过程中的假阳
  • 多样性不足：对于未知程序的知识有限。LLM会利用其训练知识来填补空白，生成错误的API调用序列。LLM更倾向于对常用的项目生成有效的驱动程序

建议1：

  • 如果目标项目的代码和使用案例已经包含在训练语料库中，使用LLM进行驱动程序的自动生成是可行的。基于已识别的错误迭代询问LLM并修复错误是一种实际的措施，有助于应对LLM易出错的挑战

  • 不在语料库中，应该收集有价值的材料（函数原型、示例程序或函数之间的连接规则）构造Prompt。提示工程是可行的方案

  • 对于复杂的项目（Linux Kernel），尽管有详细的文档，大模型可能依然无法生成测试程序，此时建议不使用LLM，使用传统方法更加可行

Input Generation

基本方法是用输入的规范和输入样例作为Prompt让LLM生成新的输入

如果直接使用LLM生成输入可能会无效，受限于训练语料库和长文本的理解能力

挑战

  • 生成的输入缺少多样性：给定Prompt，输出类似
  • 生成的输入有效性不足：目标程序执行时可能提前结束执行，因为LLM无法完全理解输入格式的长文本
    • BGP路由协议超过28000word

建议

  • 如果输入在网络中有很多样例，可以直接使用LLM生成测试用例，但是需要考虑多样性

    • Prompt要求使用多样化的特性
    • 使用基于覆盖的遗传算法

  • LLM训练时缺少相关语料，使用LLM将知识转化为输入的规范 或 建立初始的测试用例，输入规范有助于解决有效性不足的问题，而初始测试用例则有助于解决多样性不足的问题

    • 例如，对于缺乏机器可读语法的协议实现，自动生成符合必要结构和顺序的有效测试输入变得具有挑战性。在这种情况下，利用LLM已经在已有协议上进行训练的优势，可以通过LLM和记录的消息序列转移这些协议的语法。语法能够增强生成的测试用例的有效性。

Bug Detection

基本方法：将目标程序的功能描述作为Prompt的上下文，然后让LLMs生成实现与目标程序相同功能的代码，比较语义等价的两个程序的执行结果

Tsz-On Li, Wenxi Zong, Yibo Wang, Haoye Tian, Ying Wang, Shing-Chi Cheung, and Jeff Kramer. 2023. Nuances are the Key: Unlocking ChatGPT to Find Failure-Inducing Tests with Differential Prompting. In 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 14–26.

挑战：

  • 对于被测程序的语义理解不准确，可能生成功能和被测程序偏移的代码，假阳率比较高

建议：

  • 定义测试oracle高度依赖于具体的目标和场景，是模糊测试中最具挑战性的部分。对于复杂的目标，我们建议避免直接使用LLM来分析结果。相反，可以考虑利用LLM提取与特定漏洞类型相关的特征或模式，借助领域知识。随后，使用这些oracle监控系统，有助于解决理解不准确的挑战。
    • 使用LLM来仔细检查日志，识别错误模式，并随后利用这些模式检测逻辑错误。
  • 某些程序包含定义明确的文档，其中清楚地描述了预期行为，比如协议的RFC文件。对于这些情况，我们建议利用LLM的自然语言理解能力，从文档中提取预期行为，以定义测试判定标准。这有助于LLM理解目标程序的意图和设计，从而解决理解不准确的挑战。

POTENTIAL SOLUTIONS

对DBMS开展LLM-assisted fuzzing

针对驱动程序生成、输入生成和漏洞检测中的挑战，提出了三种潜在解决方案：状态感知的驱动器合成、跨DBMS的SQL转换以及基于日志的判定标准定义。我们将这些解决方案与直接使用LLM的实现进行了比较。

LLM-Enhanced Connector Synthesis

数据库连接器或数据库驱动程序通过定义的接口（包括函数和参数）将应用程序连接到数据库。模糊测试驱动程序由这些接口序列组成。直接使用LLM生成数据库驱动程序面临两个挑战。

首先是容易出错：API序列在连接器的状态中包含语义细节，直接生成序列可能会引入错误。其次是范围有限：由于训练数据的限制，LLM缺乏关于连接器状态转换的知识。

根据建议1.2，提出了LLM增强的状态感知数据库连接器合成。首先收集JDBC函数原型和使用JDBC的示例程序。然后我们将JDBC函数之间的连接关系建模为状态转换规则。接着，我们将函数原型、示例程序和连接规则作为输入提供给LLM。我们给出的提示类似于：“根据状态转换规则和函数的状态描述，请生成长度为15的API序列，要求覆盖与之前不同的状态转换组合。”

image-20241006200013351

将LLM增强的连接器合成实现为Wingfuzz𝑐𝑜𝑛𝑛，并将其与LLM𝑐𝑜𝑛𝑛进行比较，后者直接利用LLM为MySQL Connector/J、MariaDB Connector/J和AWS JDBC Driver for MySQL生成驱动程序。我们在ClickHouse上对每个工具进行了模糊测试。表1显示了LLM𝑐𝑜𝑛𝑛和Wingfuzz𝑐𝑜𝑛𝑛在三个选定DBMS上在12小时内的驱动器正确率和分支覆盖率。这些统计数据表明，Wingfuzz𝑐𝑜𝑛𝑛在驱动器正确率和分支覆盖率方面始终优于LLM𝑐𝑜𝑛𝑛。主要原因在于状态转换规则嵌入了语义信息，帮助LLM生成考虑数据库连接器内不同状态的API序列。

Cross-DBMS SQL Transfer

通过LLM直接生成SQL查询面临两个主要挑战：

确保语义正确性和促进查询多样性。复杂的SQL语法，包括各种子句、表达式和规则，使得LLM在实现语义正确性方面面临挑战，而语义正确性对于触发复杂的DBMS行为至关重要。

此外，SQL查询的多样性对于深入探测DBMS逻辑至关重要。然而，LLM的多样性受限，限制了对不同查询结构的探索。

解决方案：

不是直接创建SQL查询，而是利用LLM将其他DBMS的测试用例转移为初始种子，以对目标DBMS进行模糊测试。该方法包含三个步骤。首先，在其原生DBMS中执行现有测试用例，以捕获模式信息；其次，将模式信息提供给LLM生成新的测试用例；第三，临时注释掉无法解析的部分，以确保正确解析，然后在变异后取消注释。

image-20241006200444284

Wingfuzz𝑖𝑛𝑝𝑢𝑡生成的测试用例包含比LLM𝑖𝑛𝑝𝑢𝑡多出159.35%、36.65%和112.14%的语义正确SQL语句，并且分别覆盖比LLM𝑖𝑛𝑝𝑢𝑡多出55.96%、21.83%和16.41%的分支。这表明，LLM无法直接生成高质量的SQL查询用于DBMS模糊测试。主要原因在于，转移种子提高了变异测试用例的多样性，而模糊测试器的变异器确保了SQL查询的语义正确性。

Monitor-Based DBMS Bug Detection

DBMS漏洞检测中最关键的一步是构建测试判定标准，以识别逻辑或性能漏洞。测试判定标准决定了DBMS行为的正确性或有效性。直接使用LLMs来构建测试判定标准具有挑战性，因为LLMs缺乏关于DBMS行为的特定知识。

为了解决这些挑战，我们提出了基于运行时监控的DBMS漏洞检测方法，遵循REC 3.1，通过分析DBMS的运行时信息来检测异常。DBMS通常包含隐式的异常处理机制，以避免系统崩溃，通常会输出DBMS的关键内部状态。与通过检查SQL查询的执行结果来构建测试判定标准不同，我们的方法使用LLM分析运行时信息以进行漏洞检测。该过程包含两个主要步骤。首先，插入一个代理来提取DBMS的运行时信息。然后，使用LLM通过预定义的错误模式检测异常

image-20241006200836511

结果显示，Wingfuzz𝑏𝑢𝑔能检测到更多异常，并且比LLM𝑏𝑢𝑔产生的误报更少。这是因为运行时信息包含了DBMS的错误消息，有助于LLM分析并检测漏洞。

Conclusion

我们系统地分析了在模糊测试中使用LLM时面临的五个挑战，并通过对近期顶级会议论文的回顾确认了这些挑战的普遍性。这些挑战影响了基于LLM的模糊测试技术的有效性。为了解决这些问题，我们提供了一些建议，以帮助模糊测试的主要步骤，这些建议在我们的初步实验中已显示出有效性。