👍

Prompt Fuzzing for Fuzz Driver Generation

作者

• Yunlong Lyu - 腾讯安全大数据实验室 - 原Hopper团队
• Yuxuan Xie - 腾讯安全大数据实验室 - 原Hopper团队 - LLM方向
• Peng Chen - 腾讯安全大数据实验室 - 原Hopper团队 - 模糊测试方向

现有方案

现有的自动生成Harness的方案通常有两种技术路线

• 通过源代码构建: 从源代码库中提取API使用代码和规范进行合成
• 动态构建: 从进程的执行轨迹中提取API调用序列并进行合成

但是目前的缺点也很明显，如果使用源代码构建的技术路线的话会存在大量的误报和生成失败的案例；而使用动态构建的方案其API的输入空间仅仅就被限制到了执行过程中可达的函数，显然缩小了输入空间。

作者思路

整体框架如图所示，其实还是使用传统LLM的方式使用prompt让其生成Harness，但是其引入了三种新的后端处理思路来将LLM生成的错误harness进行剔除。

• Compile Validation: 这个是最直接的，直接将编译错误的harness剔除
• Fuzzing Validation: 通过将harness使用Sanitizer等技术编译成为二进制并进行Fuzz，如果Sanitizer对二进制报错则将其剔除。因为harness大概率存在API误用等问题
• Coverage Validation: 这个是和Fuzzing Validation结合的，在模糊测试当中也有可能存在部分API误用是Sanitizer检测不出来的，所以作者引入了覆盖率检验的方式，通过检验覆盖率在模糊测试中是否正常增长来判断harness行为是否正常。

同时在Fuzzing Validation阶段还会通过Fuzz结果收集增加覆盖率的样本，作为以后Fuzz的初始输入用例

在经过三轮验证之后的harness会将API调用序列收集到库中，而后其借鉴了模糊测试的思想，通过变异算子来对API序列进行变异以提升harness效果。

• $Insert(C,A)$：将一个API函数$A$添加到调用序列$C$中
• $Replacement(C,A,B)$：使用API函数$B$替换调用序列$C$中的API函数$A$
• $Crossover(C,S)$: 将调用序列$C$和调用序列$S$合并成为一个新的调用序列

总结

很直接和简单的思路，似乎传统方案也可以按照这个技术路线来做?