Paper Reading《SoK: Prudent Evaluation Practices for Fuzzing》

论文链接：https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=10646824
IEEE SSP 2024

1 Introduction

（背景意义）
模糊测试是发现软件漏洞的高效方法，被 Meta、Google 等企业广泛应用，且大量学术研究持续改进其技术（如覆盖反馈、领域扩展）。过去六年（2018-2023）中，顶级安全与软件工程会议上发表了超 280 篇相关论文，反映该领域的快速发展。

（现有的工作及缺点）
模糊测试依赖随机性（如输入变异、调度顺序），且环境难以控制，导致实验结果难以重现。
Klees 等人（2018）提出可重复评估框架（如多次实验、统计测试），但实际研究中对该指南的遵循情况尚不明确。

（本文的工作、关键发现和不足）
1、工作
（1）文献系统性分析
**范围：**筛选 2018-2023 年 IEEE S&P、USENIX、CCS 等顶级会议的 150 篇模糊测试论文，分析评估设计（指标、目标、基线等）、指南遵循情况及潜在缺陷。
**重点：**检查统计测试、系统误差、漏洞报告质量等关键维度。
（2）实证案例研究
选取 8 篇论文进行 artifact 重现，评估其实验可重复性，识别评估设计中的典型陷阱（如不公平资源分配、指标选择偏差）。
2、关键发现与不足
（1）现有评估的缺陷
统计测试缺失： 63% 的论文未进行统计检验，55% 使用少于 10 次实验，导致结果可信度不足。
漏洞报告质量问题： 随机抽查 339 个 CVE 中，仅 43% 有效，20% 被维护者忽略，11% 为无效漏洞。
基准使用偏差： 61% 的论文未使用标准基准，仍依赖有缺陷的人工注入漏洞基准（如 LAVA-M）。
（2）重现实验的挑战
案例研究显示，部分论文结果无法复现（如覆盖度数据不一致、基线版本过时），暴露评估设计中的隐蔽问题（如种子集不公平、环境配置未文档化）。

（总结创新点）
贡献主要包含三点：

• 系统性文献综述：量化分析 150 篇论文的评估实践，揭示行业对可重复性指南的忽视。
• 实证验证：通过 8个案例研究，具象化评估陷阱（如非标准指标、资源分配不公）。
• 更新指南：基于发现提出修订版评估最佳实践，推动领域向科学可重复方向发展。

2 Motivation

• 通过系统性分析与实证研究，填补模糊测试评估领域的方法学空白，为行业提供可落地的规范化指南。

3 Fuzzing Evaluation Guidelines

该部分系统梳理了模糊测试评估的核心准则及基准，结合背景知识与实践建议，为规范评估流程提供了理论基础。

3.1 模糊测试背景

1. 技术定义：通过变异输入或基于语法生成测试用例，监测系统异常行为以发现漏洞，现代模糊器依赖轻量级覆盖反馈（如基本块/边覆盖）。
2. 随机性挑战：测试过程中存在输入变异、调度顺序、环境依赖（如系统调用）等随机源，导致确定性执行困难。

3.2 Klees等人的评估准则

1. 基线对比（Recommendation 1）：需与相关基准（如AFL、libFuzzer）比较，证明模糊器改进效果。
2. 目标选择（Recommendation 2）：使用含已知漏洞的基准程序（如LAVA-M）或真实软件（如binutils），确保评估代表性。
3. 实验设置（Recommendation 3）：
   • 重复实验：至少30次以抵消随机性，运行时间建议24小时并绘制性能曲线。
   • 种子管理：记录种子集（含空种子），避免饱和语料库。
4. 指标设计（Recommendation 4）：核心指标为漏洞发现能力，代码覆盖（如边/基本块覆盖）作为辅助指标。
5. 统计验证（Recommendation 5）：采用Mann-Whitney U测试或引导法，排除结果偶然性，需足够样本量（如n≥10）。

3.3 FuzzBench准则

1. 种子影响：初始种子数量显著影响性能，无种子测试可凸显模糊器本质差异。
2. 语料库限制：饱和语料库难以被模糊器扩充，不适合衡量真实能力。

3.4 覆盖率可靠性准则

1. 实验设计：使用≥10个真实程序，每个测试≥10次（每次≥12小时），优先翻倍该标准。
2. 指标规范：避免AFL独特路径等非标准指标，采用lcov等通用覆盖工具，拆分训练/验证集防过拟合。
3. 结果验证：测量显著性（如t检验）和效应大小（如(\hat{A}_{12})），公开评估工件（如Zenodo）2-37。

3.5 模糊测试Benchmarks

1. 基准分类：
   • 覆盖导向：Google FTS、FuzzBench、Unibench。
   • 漏洞导向：LAVA-M（人工注漏洞，已过时）、Magma（移植真实漏洞）、RevBugBench（还原补丁）。
2. 局限性：人工注漏洞基准（如LAVA-M）与真实漏洞场景脱节，近年渐被弃用。

总结

该部分通过整合多源指南与基准，构建了从实验设计到指标验证的完整评估框架，强调可重复性、统计严谨性及真实场景适配，为后续文献分析与案例研究提供了评判标准。

4 Literature Analysis

该部分系统性分析了2018-2023年顶级会议上150篇模糊测试论文的评估实践，揭示了现有研究在可重复性、基准选择、统计严谨性等方面的不足。

4.1 研究方法

1. 论文筛选：从289篇候选论文中随机选取150篇，覆盖IEEE S&P、USENIX、CCS等安全与软件工程顶会，手动审查评估设计（指标、目标、基线等）及指南遵循情况。
2. 评估维度：检查是否遵循Klees等人的评估指南，识别威胁评估有效性的潜在缺陷（如统计测试缺失、基准选择偏差）。

4.2 研究结果

4.2.1 可重复性

• 代码与工件共享：74%的论文发布代码，但仅23%通过artifact evaluation（如USENIX、CCS的徽章机制），60%的论文未参与或失败。
• 数据透明性：仅11%共享非代码数据，45%未明确说明实验设置，导致结果难以复现2-52。

4.2.2 测试目标（3.2.2）

• 目标偏差：76%的目标为字节导向文件格式（如binutils、libpng），平均每篇论文评估8.9个目标，但76%的目标仅被一篇论文使用。
• 基准滥用：61%未使用标准基准，17%仍用LAVA-M（人工注入漏洞，与真实场景脱节），10%使用FuzzBench2-57。

4.2.3 与现有技术对比

• 基线选择：30%的论文基于AFL开发，仅35%与AFL对比，20%未比较相关state-of-the-art方法，3%未对比自身基线。
• 工具依赖：45%的研究基于非学术模糊器（如AFL、libFuzzer），33%开发全新工具但缺乏充分对比2-62。

4.2.4 评估设置

• 运行时间：56%的论文运行24小时，但27%运行<23小时，8%未说明时长。
• 资源分配：25%未明确CPU核心数，5%不公平分配（如给新方法更多核心或预处理时间）。
• 种子管理：25%未说明种子类型，5%使用不同种子集，50%未公开种子细节2-74。

4.2.5 评估指标

• 覆盖度依赖：77%使用代码覆盖（如分支/边覆盖），但45%未明确测量方法，导致结果不可比。
• 漏洞指标缺陷：59篇论文声称9.7个CVE/篇，但随机抽查339个CVE中，仅43%有效，20%被维护者忽略，11%为无效漏洞（如重复、非漏洞）2-86。

4.2.6 统计评估

• 测试缺失：63%未进行统计检验，55%使用<10次实验，15%在≤5次实验中使用Mann-Whitney U测试（样本量不足导致检验力低）。
• 效应量化不足：仅10%测量效应大小（如(\hat{A}_{12})），73%未提供不确定性度量（如置信区间）2-96。

4.2.7 有效性威胁

• 仅20%的论文讨论评估有效性威胁（如环境配置、指标偏差），缺乏对潜在问题的系统性反思。

总结

文献分析揭示了模糊测试评估中普遍存在的可重复性不足、统计严谨性缺失及指标设计缺陷，为后续案例研究和修订评估指南提供了实证依据。

5 Artifact Evaluation

该部分选取8篇模糊测试论文进行实证重现，揭示评估实践中的具体陷阱，为修订评估指南提供实证依据。

5.1 研究设计

1. 案例筛选：选择4篇2023年安全顶会论文，覆盖artifact evaluation通过与未通过的场景，聚焦评估设置、指标合理性等问题。
2. 实验环境：使用Ubuntu 22.04服务器（196GB RAM，Intel Xeon CPU），每模糊器限制单核心，运行10次×24小时实验。

5.2 核心案例分析

1. MemLock（ICSE’20

• 问题发现：人工降低目标程序栈大小以触发漏洞，未在论文中说明；依赖“唯一崩溃数”指标（实际为同一漏洞的不同表现）；26个CVE中存在同一漏洞重复申请（如mjs的6个CVE未被维护者承认）。
• 教训：避免人为修改运行环境，以真实漏洞而非CVE数量衡量效果。

2. SoFi（CCS’21）

• 问题发现：声称在浏览器引擎中发现7个漏洞，但全部被开发者拒绝（6个在投稿前已被驳回），代码缺失且未响应重现请求。
• 教训：禁止夸大无效漏洞报告，确保代码开源承诺。

3. DARWIN（NDSS’23）

• 问题发现：FuzzBench覆盖度结果不可复现（原文15/19目标表现最佳，重现仅4/18）；基线MOpt的突变限制导致性能偏差；未公开AFL 2.55b移植代码。
• 教训：公开完整基线代码，通过消融实验验证核心组件有效性。

4. FuzzJIT（USENIX’23）

• 问题发现：覆盖度较Fuzzilli下降2%-12%（原文声称提升16%-33%），语义正确率未达标；使用过时Fuzzilli版本导致对比不公。
• 教训：确保基线工具为最新版本，统一环境配置。

5. EcoFuzz（USENIX’20）

• 问题发现：使用“总路径数”非标准指标，实际分支覆盖低于AFLFast；路径数多但漏洞发现能力弱。
• 教训：优先使用行业标准指标（如分支覆盖），避免非标准指标误导。

6. PolyFuzz（USENIX’23）

• 问题发现：种子集不公平（PolyFuzz使用58个种子，对比Atheris仅39个），未公开Atheris扩展代码，初始覆盖差3倍。
• 教训：统一种子集并公开，确保对比公平。

7. Firm-AFL（USENIX’19）

• 问题发现：文档缺失（无构建说明、目标配置），预编译二进制无法从源码构建，9/11目标仅部分运行，基线AFL版本过时。
• 教训：提供清晰文档与可复现构建流程。

8. FishFuzz（USENIX’23）

• 问题发现：覆盖度测量包含ASAN工具代码，导致FishFuzz虚增8.44%边缘覆盖，标准AFL instrumentation下仅1.69%。
• 教训：使用统一覆盖测量方法，避免工具代码干扰。

5.3 共性结论

1. 可重复性挑战：63%的案例因环境配置、基线版本等问题无法复现原文结果，暴露评估文档与代码开源的不足。
2. 评估缺陷类型：种子不公平（25%）、指标设计偏差（37%）、统计方法缺失（50%）、环境未文档化（43%）。
3. 改进方向：强制公开artifact、统一评估指标、规范统计验证流程（如≥10次实验+bootstrap测试）。

总结

该部分通过具象化案例，验证了文献分析中“评估严谨性不足”的结论，为修订版评估指南提供了实践依据。

6 Revised Best Practices for Evaluation

该部分基于文献分析与案例研究，提出了一套系统化的模糊测试评估最佳实践，旨在提升研究的可重复性与严谨性。

6.1 可重复工件

1. 开源与文档化：公开源代码并提供详细文档，参与artifact evaluation（如USENIX、CCS的徽章机制）。
2. 环境标准化：指定目标程序、模糊器的具体版本（如AFL 2.55b），使用Docker等容器技术封装运行环境，避免依赖冲突。
3. 基线透明性：明确新方法基于的基线版本，保留基线代码提交记录，便于追溯。

6.2 测试目标选择

1. 代表性与可比性：选择真实世界程序（如binutils、libpng）和标准化基准（如FuzzBench），避免人工注入漏洞的过时基准（如LAVA-M）。
2. 目标说明：公开对目标程序的修改（如补丁），若目标有限制（如状态机协议），需明确说明。

6.3 与现有技术对比

1. 基线全面性：对比当前state-of-the-art模糊器（如AFL++、libFuzzer），若基于现有工具开发，需与基线版本严格对比。
2. 消融实验：通过拆分组件验证核心技术贡献（如动态变异调度vs随机调度），避免将改进归因于整体实现。

6.4 评估设置

1. 运行环境：记录硬件配置（CPU核心数、内存），运行时间≥24小时，单核心运行以避免资源竞争，使用虚拟机隔离实例。
2. 种子管理：使用无种子或统一种子集，公开种子细节（如空种子、项目测试用例），确保所有模糊器使用相同种子。

6.5 评估指标

1. 标准化指标：核心指标为漏洞发现能力，辅以代码覆盖（如边覆盖），避免AFL独特路径等非标准指标。
2. 覆盖度测量：使用lcov等通用工具，明确覆盖度计算方式（如排除工具代码），避免位图碰撞导致的误差。
3. 漏洞验证：优先报告经维护者确认的漏洞，避免同一漏洞重复申请CVE，不强制以CVE数量衡量影响。

6.6 统计评估

1. 实验次数：至少10次独立实验，通过先验功效分析确定样本量，避免小样本导致的统计效力不足。
2. 方法选择：使用bootstrap、置换测试等非参数方法，替代Mann-Whitney U测试以处理非正态分布数据。
3. 多重测试：采用ANOVA结合Tukey-Kramer事后检验，处理多模糊器对比时的多重假设检验问题，测量效应大小（如(\hat{A}_{12})）并报告置信区间。

总结

该部分通过整合可重复性、公平对比、统计严谨性等维度，形成了覆盖工件管理、指标设计到结果验证的完整评估框架，为模糊测试研究提供了可落地的规范化指南。

7 Conclusion

该n部分总结了研究核心发现，强调模糊测试评估中可重复性的重要性，并基于实证提出未来研究方向。

7.1 核心研究成果

1. 文献分析结论：系统性审查2018-2023年150篇顶会论文，发现评估实践中存在统计测试缺失（63%未进行）、CVE有效性低（仅43%被确认）、基准选择偏差（61%未用标准基准）等关键问题。
2. 案例验证发现：8个artifact重现案例中，多数结果因环境配置不透明、基线版本过时等原因无法复现，暴露评估设计的隐蔽缺陷（如种子集不公平、非标准指标滥用）。

7.2 方法论贡献

1. 问题量化：通过数据揭示模糊测试评估在可重复性、统计严谨性、指标合理性上的系统性不足，例如仅23%的论文通过artifact evaluation，5%存在资源分配不公。
2. 指南更新：提出修订版评估准则，涵盖可重复工件管理、公平对比基线、标准化指标（如漏洞发现+代码覆盖）及统计方法（≥10次实验+bootstrap测试）。

7.3 未来研究方向

1. 工具开发：构建自动化评估框架，支持多指标关联分析（如覆盖度与漏洞发现的因果关系），提升评估效率。
2. 深度探索：研究防御变体（如不同公平性算法）对评估的影响，引入因果推理验证交互效应，扩展至生成模型等新兴领域。
3. 社区实践：推动评估指南的行业采纳，例如将artifact evaluation纳入顶会投稿强制要求，提升领域整体科学严谨性。

7.2 总结

结论强调，模糊测试作为软件安全的核心技术，其研究必须以可重复性为基石。本文通过实证分析与准则修订，为构建更科学的评估体系提供了理论与实践基础，未来需在工具支持、跨场景验证中持续优化。