白泽带你读论文 | V0Finder

AI 2周前 admin
58 0 0

如需转载请注明出处,侵权必究。


本文发表于USENIX 2021,第一作者是来自高丽大学的Seunghoon Woo博士,这篇工作是他在攻读博士期间完成的。

作者在论文中创新地提出了“零号漏洞”(Vulnerability Zero,VZ)的概念,其意义与传染病学中的零号病人类似,即某个漏洞最初起源的软件。正确地定位VZ有利于从漏洞的根源代码中修复问题,并且可以阻断漏洞传播到复用VZ代码的其他软件。作者提出了V0Finder,是一种用于从软件池中发现 VZ 的精确机制。工具从某个特定漏洞的相关信息出发,从软件池中识别该漏洞起源的软件名称及其版本。V0Finder利用基于代码的分析,来识别易受特定漏洞攻击的软件之间的重用关系,以此构造一个漏洞传播图,并且利用后向跟踪方法找到漏洞传播图的根结点以定位 VZ。

作者将V0Finder应用于国家漏洞数据库(NVD)和Bugzilla项目中收集到的5,671个CVE漏洞。结果表明,V0Finder在定位VZ方面具有98%的精度和95%的召回率。此外,V0Finder还发现上述CVE披露中的96个给出了错误的VZ信息。作者通过调研发现,不正确的VZ会导致受漏洞影响软件的补丁部署时间延长。VZ信息错误的受影响软件,其补丁部署平均需要2年左右,而VZ正确的受影响软件,补丁部署平均耗时不到一年。结果显示,CVE披露中错误的VZ信息会阻碍漏洞披露的本来目的(更加快速而有效地鉴别、发现和修复软件产品的安全漏洞),并导致开发者在安全方面的混淆。作者的分析表明,V0Finder可以有效提高CVE提供的信息的可信度。



背景

当前针对漏洞报告的研究主要可以分为三类:

  1. 识别漏洞报告中缺失的信息,以有效缓解漏洞带来 的影响

  2. 分析漏洞的可复现性

  3. 确保漏洞描述与受影响的软件信息之间的一致性。

以上的研究都是基于CVE报告进行分析,但是对于报告中漏洞的起源VZ,缺少合适的验证手段。如果上述研究是基于VZ错误的公共漏洞报告,那么其结果的可信度可能会受到挑战。

问题描述

作者针对VZ错误的问题给出一个现实世界的例子,如图1-1所示。CVE-2017-0700这个漏洞在CPE(Common Platform Enumeration)中被报告给了安卓系统,并且受影响的版本也被标注为安卓系统的某个版本。

白泽带你读论文 | V0Finder

但是,实际上漏洞的真正源头是安卓系统中引入的上游软件,GDX库中的 JPEG-compressor,即真正的VZ。但是漏洞却被报告给了 VZ 的下游软件安卓系统,并且被公开披露。

白泽带你读论文 | V0Finder

作者认为,报告中错误的VZ索引会使得相关软件的漏洞修复受到较大影响。(1)对于复用Android系统的软件:因为该漏洞是报告给Android系统的,复用Android 7.1.1或7.1.2版本的软件程序,可以轻松地定位此安全问题并且修复漏洞,例如直接将Android系统更新到更高版本。(2)对于仅复用JPEG-compressor的软件:相关维护人员对Android系统披露的漏洞可能并不感兴趣,因而几乎不会检查其代码库是否受到该漏洞的影响。因此,此类软件程序大多未能及时检测并修补漏洞。事实上,如图1-2所示,JPEG-compressor、Godot2和LibGDX3等实际VZ和复用VZ的软件的最新版本都包含易受攻击的漏洞代码。通过使用精心构造的图像文件作为输入,作者成功在上述三个流行软件的最新版本中复现了这个漏洞。

挑战

发现正确的VZ需要解决以下两个技术挑战:

  1. 解决易受攻击代码的语法多样性,当包含漏洞代码的软件在更新或被其他软件重用时,易受攻击代码的语法经常发生变化。

  2. 选择合适的特征来发现VZ,方法需要选择合适的特征来确定易受攻击的软件为VZ。直观的想法是将创建时间最早,并且存在漏洞的软件识别为VZ。然而作者发现,软件源代码在发布后可能会发生变化。此外,由于复制和粘贴等操作,代码生成时间也很容易改变。

方法论

作者给出V0Finder的总体架构。如图所示,方法包括三个阶段:

1. 结点发现阶段(node discovery phase)。

2. 边连接阶段(edge connection phase)。

3. 根发现阶段(root finding phase)。

白泽带你读论文 | V0Finder

第一阶段

利用漏洞代码克隆检测技术,输入导致CVE的漏洞函数V,从给定的软件项目集合中,搜索出所有存在漏洞的软件项目。

1. 预处理:文本预处理和LSH(局部敏感哈希)。

   a. 文本预处理移除空格、换行、注释,然后把所有代码转换成小写。

   b. 在文本预处理基础上采用LSH,计算出代表相似程度的散列值。

2. 比较:根据散列值计算每个软件项目和漏洞函数V之间的距离值Φ(代表两份代码的语义近似程度),并且设定好一个阈值θ。

   a. 如果距离Φ为零,认为软件项目中的函数是漏洞函数的一个未补丁克隆。

   b. 如果距离Φ介于0-θ之间,认为软件项目中的函数是漏洞函数的修改后克隆,由于修改行为可能是打补丁,所以需要额外的验证步骤。

   c. 如果距离Φ大于θ,认为没有克隆关系。

白泽带你读论文 | V0Finder

第二阶段

识别每对软件项目之间是否存在重用(reuse)关系,并构建漏洞传播图。

1. 基于公共代码占比的识别,适用于没有代码修改的场景。计算公共部分占项目中所有函数的比重,认为比重小于1的项目复用了比重等于1的代码。

如下公式所示,当α<1.0并且β=1.0时,认为带撇的被不带撇的重用,交集指代相同散列值方法的数目。

白泽带你读论文 | V0Finder

2. 基于源代码位置的识别,适用于有代码修改的场景。提取两个项目内公共函数的代码文件项目路径,认为文件路径长的重用了文件路径短的代码。如果路径一样长,就不认为有重用关系。

3. 基于元数据文件的识别,适用于代码和结构都被修改的场景,首先提取README,LICENSE和COPYING等元数据文件。如果文件内容字符串比较相等,接着判断元数据文件是否保存在项目根目录,元数据保存在根目录的被认为是被重用的软件。

第三阶段

通过寻找图的根结点来找到漏洞函数V的源头VZ。此步骤有可能识别出不同数量的根结点,下面描述不同数量根结点产生的原因。

1. 单个根结点,代表VZ在软件池中,并且V0Finder成功识别漏洞软件之间的重用关系。

2. 两个或更多根结点,VZ可能不在软件池,或者V0Finder没有识别出某些重用关系。

3. 零个根结点

 (1)VZ不存在(比如算法漏洞,密码学算法,重用关系不明确),这种情况将被忽略。

 (2)漏洞没有被传播到其他软件(图只有一个结点,就认为此节点是VZ)。

 (3)完全无法识别重用关系,也就是说V0Finder漏报了。

实验评估

评估方法:NVD中的CPE(Common Platform Enumeration)披露了受CVE影响的软件程序及其版本,作者将工具的分析结果与NVD做比较。当两者一致时,作者认为分析的结果是正确的。相反,如果定位的VZ不包含在CPE中,作者将进一步分析以确定其正确性。V0Finder和NVD可能同时为CVE提供了不正确的VZ信息;但是,研究人员的漏洞报告(即NVD信息)和实际代码级识别(即V0Finder的结果)相同的情况下,这些VZ很可能是正确的。

V0Finder最终发现95%的VZ在CPE上是归档正确的,但是有96个CVE的VZ归档是错误的。工具最终达到99%的精确度和97%的召回率。

白泽带你读论文 | V0Finder

然后作者指出定位正确的VZ的重要性:首先是VZ对开发人员检测和修复漏洞成功率的影响。正确VZ使软件漏洞修复的成功率达到85%,错误的VZ使得只有36%的受影响软件意识到并且成功修复漏洞。

其次是,VZ对开发人员修复漏洞所耗时间的影响。错误的VZ使得漏洞的平均修复时间远超在正确VZ指导下修复所耗费的时间。实验数据表明,正确VZ指导下的平均修复时间在300天左右,而错误的VZ对应漏洞的修复时间在500天左右。

总结

作者的结论是,漏洞报告的质量控制对开发人员检测和修复漏洞非常重要。作者提出V0Finder工具,可以在漏洞软件池中精确定位漏洞源头。开发者可以利用VZ定位的结果有效解决项目复用软件的漏洞问题。

Q&A

Q1:正确识别VZ的重要性

   1.不正确的 VZ 让 CVE 漏洞的检测更加困难

   2.不正确的 VZ 导致更长的补丁部署时间。


Q2:精确识别 VZ 面临的两个挑战

   1.解决易受攻击代码的语法多样性;

   2.选择合适的特征来发现VZ。

Q3:为什么静态/动态工具不能解决 VZ 错误问题?

使用静态或动态工具(例如模糊测试工具)扫描漏洞的方法不能从根本上解决所提出的问题。这种方法只关注特定软件的内部漏洞,需要对所有受影响的软件程序重复运行工具。作者希望提出一个一站式的解决方案来代替这种低效的解决方案,来检测漏洞的正确VZ,并一次性通知所有受影响的软件程序。

Q4:V0Finder如何识别受特定漏洞影响的软件?

1. 预处理:文本预处理和LSH(局部敏感哈希)。

   a. 文本预处理移除空格、换行、注释,然后把所有代码转换成小写。

   b. 在文本预处理基础上采用LSH,计算出代表相似程度的散列值。

2. 比较:根据散列值计算每个软件项目和漏洞函数V之间的距离值Φ(代表两份代码的语义近似程度),并且设定好一个阈值θ。

   a. 如果距离Φ为零,认为软件项目中的函数是漏洞函数的一个未补丁克隆。

   b. 如果距离Φ介于0-θ之间,认为软件项目中的函数是漏洞函数的修改后克隆,由于修改行为可能是打补丁,所以需要额外的验证步骤。

   c. 如果距离Φ大于θ,认为没有克隆关系。

Q5:V0Finder如何验证克隆代码的修改是否是补丁?

利用CVE给出的补丁,如果克隆代码包括所有在补丁中被删除的代码,并且没有补丁的过滤代码,则认为克隆代码依然存在漏洞,不是补丁。

Q6:漏洞传播图中识别出多个根结点如何处理?

人工干预,V0Finder会检查所有根结点内的公共函数,公共函数的路径(path)信息会强烈提示VZ,例如路径中带有Bzip2。

Q7:为什么LSH算法选择TLSH?

使用TLSH算法的相似性检测导致误报较少,具有合理的散列和比较速度。此外,与其他算法相比,它受输入大小的影响较小。

Q8:作者未来的研究方向

首先,作者将考虑由复制和粘贴小段代码引起的漏洞传播。为了解决这些问题,应该选择重用关系标识以外的特征;作者正在研究一种扩展技术来处理此类情况。其次,由于V0Finder的方法可以应用于其他语言,作者希望在其他语言上识别VZ,这就需要为新语言构建CVE和软件池。


文案:WHT

排版:YST

戳“阅读原文”即可查看论文原文哦~

复旦白泽战队

一个有情怀的安全团队

还没有关注复旦白泽战队?

公众号、知乎、微博搜索:复旦白泽战队也能找到我们哦~


原文始发于微信公众号(复旦白泽战队):白泽带你读论文 | V0Finder

版权声明:admin 发表于 2022年11月22日 下午3:33。
转载请注明:白泽带你读论文 | V0Finder | CTF导航

相关文章

暂无评论

暂无评论...