【论文分享】Facilitating Vulnerability Assessment through PoC Migration

CCS 2021 ，来自复旦白泽的论文

论文链接：https://dl.acm.org/doi/abs/10.1145/3460120.3484594

开源，需要身份认证：https://seclab-fudan.github.io/VulScope/

简介：有研究表明，MITRE/NIST的漏洞报告，关于漏洞版本的信息有缺失，使得没有报告的漏洞版本存在很大的安全隐患。这篇文章，通过基于fuzz的方法去解决这个问题。技术上来说，这个方法首先收集软件参考版本的崩溃路径，然后使用这个路径去指导目标版本程序的poc输入的变异。让目标版本可以沿着与参考版本相同的路径执行。看是否存在相同的漏洞。

背景

MITRE和NIST已经整理好了超过150K个的漏洞，并且整理为漏洞报告。一个漏洞报告通常包括漏洞软件版本、漏洞的危害以及用来复现漏洞的poc输入。这些信息对补丁开发、漏洞管理和安全评估起到了作用。

然而，目前的研究开始关心漏洞报告的质量问题。有四个工作认为这些报告中的软件版本不准确。这些不准确的信息会让特定版本的程序不会被修补，导致安全隐患。

为了解决这个问题，Dong等人，用一个版本的有效的poc，对另外一个版本进行测试。他们发现，如果不修正poc的话，某版本程序的poc很难触发另一个版本的漏洞。而且，他们观察到，在一个版本上验证漏洞需要花费很长的时间。为了解决人工操作并且提高漏洞验证的上限，可以采用代码克隆检测和补丁存在测试的方法。这两种都是静态分析方法。

• 代码克隆检测可以定位到漏洞代码的位置
• 补丁存在测试可以定位安全补丁是否存在

然后，就可以推断出要检查的软件版本是否存在潜在漏洞。然而，传统的静态分析工具会产生巨大的误报，因为他们不能生成触发漏洞的poc。有poc在手，就可以辅助补丁开发，回归测试和目标漏洞的可利用性评估。

由于这些限制，另一个方向是使用定向模糊测试。具体来说，如果能够在目标版本中给定有漏洞的位置，就可以用参考版本的PoC输入作为定向模糊测试的初始种子。不像传统的模糊测试是最大化覆盖率，定向模糊测试的目标是生成能够到达目标位置的输入，从而探索潜在漏洞的位置。文章认为这种做法在poc移植上效果不错。然而，定向模糊测试效果并不好，其原因在于定向模糊测试能够快速找到目标点的位置，但是会忽视触发目标bug的条件。

方法

这篇文章提出了一种PoC移植的方式，能够调整参考PoC去最大化参考执行路径和目标执行路径的相似度。核心思想是在不同版本里触发相同漏洞的执行流应该是相似的。基于参考路径，本文的方法避免了盲目探索大量能到达漏洞位置的路径，更加针对那些在参考版本里能行的路径。与现有工作相比，我们的方法有更多的机会和效率能够在目标版本生成新的poc。

方法具体来说可以分为六个步骤：

1. 分别收集$T_{ref}$和$T_{target}$，这两个分别表示给定参考版本的poc的路径，和用参考版本poc运行目标版本的路径。
2. 确定两条路径上对齐的函数。
3. 如果目标版本上发生了crash，追踪crash去看是不是由于目标漏洞导致的crash。
4. 定位导致执行变化的关键变量。执行变化指的是目标版本和参考版本执行轨迹上不同的地方。
5. 使用基于fuzz的方法去变异与关键变量相关的输入变量来修正变化的地方。
6. 所有变异的输入都会去追踪crash，并且基于他们的trace和参考trace的相似度给出一个分数。如果没有种子能够触发目标漏洞，就会根据分数被插入到优先队列中。得分高的种子就会被选来用做下一轮的变异。

实验

原型：4.5k行的C++代码和2k行的python代码。静态分析基于LLVM 7.0.0实现，fuzzing 部分基于AFL 2.56b实现。污点分析基于PolyTracker实现。

数据集选择有以下信息的漏洞：

• 有poc
• 有漏洞软件的版本
• 有漏洞软件安装的指导
• 有触发漏洞方式的指导，因为有的poc需要在某些参数下才会触发

setup：

• 在8G内存和2G虚拟机里运行
• 宿主机是intel i7 9750H，和我电脑一样
• 运行工具运行8个小时

总共做了五个实验：

1. 有多少漏洞版本是参考PoC就能够直接触发crash的？在这些触发的PoC里，有多少是和参考版本一样的漏洞？对于那些没有触发crash的版本，有多少是需要VulScope去做PoC移植的？
2. vulscope在移植PoC上有多好的效果？
3. 评估cross-version trace alignment的性能。包括了如下几个问题：
   • traces的大小有多大？
   • 代码重构的频率多吗？
   • 路径中的源代码的变化频繁吗？
   • 本文路径对齐的方法的是否有效和高效？
4. 和现有的fuzz工具（AFLGo，AFL）对比，有什么优势？
5. vulscope在验证一个软件的漏洞版本上有多好？将工具和NVD报告的漏洞软件版本进行比较。

讨论

主要讨论了三个问题：

• 用符号执行去修正执行变化的可能性
• 应用到闭源二进制的可能性
• 局限和未来工作

用符号执行去修正执行变化的可能性

修正执行路径的变化去触发目标漏洞是很难的，由于以下三个原因：

• 一些执行变化对触发目标漏洞不重要
• 可能会报告不正确的执行变化
• 一些执行变化可能会互相矛盾，意味着只能选择其中某个去修正

总的来说，很难去确定精确的集合去修正这些变化，所以不能应用符号执行，因为需要知道哪些执行需要修正。

应用到闭源二进制的可能性

从high-level层面来说是可以的。

局限和未来工作

• 应用后向污点分析去定位可能会影响关键变量的值的关键输入，因此会遇到overtaint和undertaint的问题。缓解的方法是用input probing技术。
• 树对齐算法是采用layer-by-layer的设计，可能会在代码变化比较大的出现问题。提升的方法是用更先进的代码相似度比较算法。
• 不能处理复杂的代码重构情况，比如函数同时合并和分开。
• 当推断执行变化的时候，只考虑了四种常见类型的crash。其他类型的crash触发的时候就不能找到对应的关键变量。
• 需要遍历调用图来识别函数合并和分支对。实现中并没有考虑间接调用。
• 核心思想是沿着参考路径走可以帮助触发其他版本的同一个漏洞。然而，也有情况是目标版本触发漏洞的条件和参考版本不一致。这种情况下，可能需要辅助root cause analysis的技术。

总结

这篇文章思路很不错，从实际问题出发，解决了一个很有价值的事情，值得细细品味。

从论文写作上的呈现来看，感觉能看出作者对所做问题的思考。很多地方的选择都给出了有理有据的解释。