G.O.S.S.I.P 阅读推荐 2022-07-18 VulnFix

从安全开发周期的视角来看，漏洞挖掘与 PoC 仍然不是终点。尤其是当你申请一些要求严格的 CVE 编号时（比如 Linux Kernel），还需要为相应的代码提交 Patch 才能获取。可想而知，当开源社区接受越来越多的 CVE 时，他们也增加了许多打补丁的工作，而这一切其实都可以交给自动化的程序修复工具，听上去是不是非常的fancy~

之前我们曾经介绍过关于自动化修复Android APP 兼容性问题的论文，今天我们继续探索这个方向，关注漏洞的自动化修复，推荐一篇来自 ISSTA 2022 的研究论文 – Program Vulnerability Repair via Inductive Inference，针对如何高效准确地通过归纳推理生成补丁进行深入探讨。

目前最主流的自动化程序修复（APR）方法通过推理出漏洞所在位置的某个不变量（文章称为 patch invariants，可以理解为一个表达式）。不变量的性质和实际的程序状态紧密相关：当程序状态良好时，不变量成立；程序遇到可以触发漏洞的输入时，即遭遇到 crash，failed sanitizer check 等 fuzzing 中可以观测到的问题时，不变量不成立。而自动化修复就是要求生成的 patch 能够满足如下性质——在漏洞所在位置保证 patch invariant 总是成立。

Patch invariant 这样的不变量可以通过静态（符号执行）或者动态（混合符号执行）的方法获取。静态的方法需要大量的计算来探索路径，而动态的方法依赖于 test case，容易陷入过拟合的问题。本文在动态方法的基础上，提出了基于反例引导（counter example）的方法，来生成更多的 test case。此外，考虑到低效的 Input-level fuzzing 往往是覆盖率引导的，而不是直接定向到漏洞位置，本文使用了快照模糊测试（snapshot fuzzing）的方式。从下图中可以看出，其直接在程序状态上变异，解决了路径可达性问题，为后续的推理不变量提供更丰富有效的 test case。

论文设计了名为VulnFix的工具，其主要工作流程如下图所示，其中 fuzzing 部分将已知的漏洞脚本和位置作为输入，使用了E9Patch（可以参考我们之前的论文推荐） 作为插桩工具得到大量的程序状态。将程序状态分为良好和漏洞两类后，作为输入给推理引擎，并不断迭代上述过程，直至产生单个不变量。需要注意的是，本文对于如何将不变量转化为补丁不作研究，只是采用了两个简单的方式（即加入判断条件或者是if-guard）。

为了验证论文提出的创新点，作者一共设计了三个实验：

RQ1: Efficacy with different backends

该实验比较了采用两种不同推理引擎生成的 patch 结果：Daikon 和 cvc5 backend 都在包含39个可复现的漏洞数据集 VulnLoc 中生成了19个正确的 patches，分别花费了30分钟和3小时。此外，从结果和打补丁的机制来看，Daikon 是更好的选择。

RQ2: Comparison with other APR tools

和基于混合符号执行的 CPR 和基于符号执行的 SenX 在相同实验环境下比较，两个工具在30分钟内各生成了4个正确的 patches。作者发现 CPR 的 test case 很难达到漏洞点，而 SenX 的补丁方式难以评估，总而言之效果是没有VulnFix好啦。

RQ3: Comparison with input-level fuzzing

为了证明快照模糊测试在生成程序状态上的优势，作者将VulnFix与 AFL 和 ConcFuzz 两个传统的 input-level fuzzing工具做了对比，发现 AFl 和 ConcFuzz 分别生成了2个和6个正确的 patches，其原因在于生成的不变量过多，而且仍然有前文提到的过拟合的问题。关于 fuzzing 部分的原理介绍和讨论可以详细看论文的第三章。

顺便打个广告~论文作者的团队最近在自动化程序修复上有一个长期的计划，招收研究助理和博士后，详情请看：https://nus-apr.github.io

---

论文Artifical Evaluation：
https://zenodo.org/record/6535557#.YtQs0y8Rr5h

论文PDF：
https://abhikrc.com/pdf/ISSTA22.pdf

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2022-07-18 VulnFix