Usenix Security 2022 FIXREVERTER A Realistic Bug Injection Methodology for

作者：ZenongZhang
研究助理
德克萨斯大学达拉斯分校的四年级博士生
达拉斯， 德州， 美国
zenong@utdallas.edu

背景

•关键问题是使用什么样的绩效衡量标准。
•FuzzBench采用的一个流行的衡量标准是代码覆盖率。最近的一项研究发现，虽然覆盖范围与fuzzer发现的缺陷数量之间有很强的相关性，但如果使用覆盖范围来比较fuzzer，则对于哪种fuzzer更好并没有很大的一致意见
•另一个流行的方法是计算不同的导致崩溃的输入信号的数量，也就是独特的崩溃。研究发现会产生许多误报。

四个小目标（Goal）：

•目标程序应当和现实世界相关
•程序中应当包含现实 bug
•要能清晰地判定 bug 触发以避免去重（deduplication)的问题
•benchmark 要能抵抗过拟合（overfitting）
•现存的模糊基准没有一个满足所有这些标准。
•FixReverter 通过观察大量bugfix归纳出了三种常见修复模式（bugfix pattern），可以通过自动匹配并逆转程序中的修复模式来达到注入现实 bug 的效果，作者还基于FixReverter 开发了RevBugBench，并集成到 FuzzBench 中对5 种 fuzzer进行了评测。
•通过观察六个开源软件和Magma数据集中一共814 个 CVE，作者最终使用了 170 个CVE 匹配出三种通用的修复模式，即 conditional-abort (ABORT),
conditional-execute (EXEC) 和 conditional-assign (ASSIGN)。

ABORT

就是在下游代码解引用（dereference）某一变量之前检查其是否满足某一不变式（invariant），若不满足则直接跳出控制流，如下图就是 ABORT 模式修复空指针解引用的一个例子：

EXEC

就是在现有条件语句里再加上一个布尔表达式来检查条件体里被解引用的变量是否满足某一不变式，这样的修复使true 分支的条件更为严格，如下图就是 EXEC 模式修复空指针引用的一个例子：

ASSIGN

就是在下游代码解引用某一变量之前加上一个 if 语句给变量赋新值，如下图就是ASSIGN模式修复越界写错误的一个例子：

这三种模式都和条件语句相关，解引用代码所处的位置可能在条件表达式内或是随后的程序中，这影响了不同 pattern 所适用的语义条件（semantic condition）。

整体架构

•当然这样注入的bug 可能有一些质量并不高，RixReverter 会用naive bug filter 筛除掉。
•需要一个诊断（triage）的过程来判断哪些是产生
crash的必要 bug，最终区分如下两类原因：
•当程序输入 在注入单个 bug（假设为 A）就足以导致 crash 时，认为A是触发 是 individual cause
•当程序输入只有在注入多个 bug（假设为A,B）才导致 crash 时，认为触发原因是combination of A and B
•Bug triage 的算法就是先找invidudual causes 再找 combination causes。
作者共选择了 10 个目标程序，其中8 个来自 FuzzBench，另外 2个是 binutils 中常用的两个工具。如下表所示，经过语法匹配、静态分析和最终筛选之后一共注入了超过7900 个 bug，静态分析丢弃了最初语法匹配所得 bug 中的71% ，而 naivebug filter 只筛除了 102 个bug。

评估

作者把RevBugBench 集成到FuzzBench 以对不同fuzzer
探索现实应用中bug 的能力做大规模且可复现的评估。具体来说扩展了 FuzzBench 的三个关键组件，即benchmarks(target programs), measurer (on-the-fly result analyzer) 和 reporter(statistical analysis of results)。
•作者通过观察CVE 中的 bugfix pattern，运用语法匹配和静态分析来查找并逆转这些pattern，提出了 FixReverter 这一自动注入bug 的框架，让 benchmark随着新插入的bug 和新的 pattern不断进化。
•作者表示后续会在静态分析上进行改进，让结果更加sound。还有就是扩展新的 bugfix pattern，作者计划引入新的 pattern 不涉及控制流变化，而是定义新的semantic condition。