原文标题：Automatically Identifying CVE Affected Versions with Patches and Developer Logs Automatically Identifying CVE Affected Versions with Patches and Developer Logs
原作者：Yongzhong He，Yiming Wang，Sencun Zhu，Wei Wang*，Yunjia Zhang，Qiang Li*，Aimin Yu
发表期刊：IEEE Transactions on Dependable and Secure Computing
原文链接：https://ieeexplore.ieee.org/document/10093112
主题类型：漏洞版本影响、开发人员日志
笔记作者：octopus
主编：黄诚@安全学术圈
计算机系统的源代码漏洞对用户和组织造成了严重的威胁，安全人员研究这些漏洞的一个重要数据来源是漏洞数据库，如CVE、NVD、SecurityFocus，其中NVD数据库是目前使用最广泛、最权威的数据库之一，但是，来自NVD的漏洞信息真的真实可靠吗？具报道显示：只有59.82%的漏洞CVE摘要严格匹配标准化NVD条目，且不一致程度随着时间的推移而增加。
为解决NVD误报率与漏报率高提供一个实际的解决方案，研究者据提交依赖关系将所有软件版本构建成一个版本树，并提出了一种通用的方法，利用补丁和开发人员日志信息来验证哪些版本是真正脆弱的，并进一步确定版本树中CVE漏洞的版本号边界(例如，第一个和最后一个脆弱版本)。最后，作者修正了11,827个错误的Linux内核报告，并确认了94个补丁版本在变更日志中缺少相应的提交记录。
寻找一个令人信服的证据去证明受CVE影响的脆弱版本
高效的识别检测出所有受漏洞影响的软件版本集合
随着版本更新，漏洞代码可能修改很多遍，导致漏洞与新版本不完全匹配，需要新的技术去匹配检查漏洞
论文主要方法如下：
版本树如图：
其中，红色三角节点表示脆弱节点，带有绿色虚线圈的红色三角节点表示未打补丁的脆弱版本，蓝色节点表示未知节点
构建依据：
作者通过git-log获得提交日志，通过递归地遍历版本的提交日志到它的父节点和父节点的提交日志来构建版本树，以Linux操作系统为例，团队在Linux内核官网公开了版本类型，包括主分支版本(Mainline)、稳定版本和长期版本。主分支版本是版本树中每个垂直分支的起点版本，它在前一个主分支版本的基础上引入了所有新功能。从主分支版本开始，新的稳定版本陆续发布，形成版本树的主干。基于此协议，在Linux内核的版本中按数字来构建版本树。
释义：
第一个版本称为根节点(如)，节点称为主要版本，节点称为小版本，使用和来表示整个版本树中第一个和最后一个漏洞版本，从𝑅1、𝑅2、𝑅3三个方向搜索其他易受攻击的版本。𝑅1是查找第一个漏洞版本的方向，𝑅2是找最后一个漏洞版本方向，𝑅3是寻找整个版本树的实际最后版本。
构建方法
通常，有一个或多个补丁可以修复CVE。在大多数情况下，一个CVE-ID对应一个git日志，一个git日志由一个commit-id标识。但是，当CVE有多个补丁时，有时需要多个commit-id来修复一个CVE。只要修改的代码被提交，就会创建git日志。因此，每个补丁版本都由一个或多个commit-id唯一标识，作者通过获取CVE-ID对应的commit-id来遍历可用的日志从而获得漏洞版本集。
引出问题：在最后一个提交补丁后的版本之后，可能存在未打补丁情况，是由于开发者可能认为之前的补丁不完美或者补丁引入了新问题，所有新版本可能回到未打补丁状态进行补丁重写，从而混淆最后一个脆弱版本的检测。
解决前提：作者的工具基于补丁正确性，只考虑早期补丁是正确的重写，然后完全或部分地重写，最后用更好的补丁重写。我们不考虑错误或不完整的补丁。
解决方法：首先定位到提交版本集的最高版本，如上图，此后根据精确匹配识别此后的主要版本中是否存在未打补丁代码，如不存在，即为最后一个版本。如果存在该未被修补的diff块，未避免上述问题发生，作者首先检测该脆弱版本文件git日志列表，确定其是否存在未打补丁状态，如果不存在，则确定其为最后一个脆弱版本。如果存在，则有可能存在重打补丁状态，则检测git日志中是否存在修补程序，该修补程序是否对应该脆弱文件，并相应的找到其diff块，如果该版本代码已被重打补丁，则认为其是安全的，则为，相反，如果其未打补丁，则认为它是最后一个脆弱版本。
引出问题：分支上的版本可能不是长期稳定版本，便失去维护，所有，尽管提交的版本集中没有涉及到，但这些分支中可能存在脆弱版本，并且一些版本可能不存在提交日志。
解决方法：通过CVE漏洞发布时间()确定每个分支的最后一个脆弱版本，与(该主版本的最后发布时间)进行比较，如果，证明当前分支版本发布时间早于漏洞发布时间，再进行补丁匹配，判断其是否存在脆弱代码，若完全匹配，则认为其为最后一个脆弱版本。如部分匹配，将采用部分匹配法(即下一小节方法)，若不匹配，则从更前的版本进行匹配，从而确认边界。
引出问题：无法直接将第一个提出该CVE漏洞的commit-id作为，因为之前的版本也可能存在但是没有日志信息，而CVE漏洞在经历了很多版本更新后代码会有很大的变动，所以将其与早期版本代码匹配成为最困难的问题。
解决方法：过git日志和部分匹配来判断代码是否存在CVE漏洞，从而确定第一个漏洞版本。
三种匹配：
该类匹配源代码SF包含了DF(由sub和oth组成)中sub的所有代码，但调用的函数有不同的名称。
该类匹配源码包含部分sub的代码，至少包含oth的一个字句
该类匹配源码包含定位脆弱函数的上下文函数，名称可能不同，但仍有可能是相同的脆弱函数
匹配思想：源代码与DH存在至少一行的代码匹配，使用一到两行匹配的代码作为锚点，在源代码的函数(Fun)中选择三个代码块。若只有一行匹配，取源代码中匹配码前一行为一块，匹配行为第二块，后一行为第三块，当有两行或两行以上匹配的代码时，第一个匹配码和最后一个匹配码之间的源代码中的代码构成第二个块，第一个和第三个块按照前面的方法选择，从而匹配这三个代码块完成部分匹配。
作者在部分匹配源代码后，通过追踪日志方法，寻找到不同版本所共享相同的源代码片段，如上图SF3、SF2，通过diff工具找出两块的差异，由于每次更新都会产生记录差异的git日志，便可以以此来遍历在以前时间节点的每个git日志，将日志中的diff块与每一个sf-diff块匹配，再而手动确定是否存在漏洞。
首先在版本树中对每个主版本进行精确匹配，如果都匹配成功，则第一个就是最早版本。否则，通过上述的日志追踪方法，例如，若最后一个版本如V2.6完全匹配，若在V2.5版本不存在或无法验证，则认为V2.6是第一个，否则将采用逆序方法，通过追踪日志找到第一个版本。
本文主要选择的产品有Linux kernel、Openssl、BusyBox、Wget和QEMU，包含1367个CVE文件，漏洞类型包括buffer overflow、integer overflow、SQL injection、use-after-free等，收集了NVD从2003年1月到2020年9月发布的Linux内核漏洞，总共有2576个CVE - id。其中，在https://git.kernel.org上发表的有1367个，包括2664个补丁，一共收集了3,086个Linux内核版本，组成了版本树，占用了585G的数据空间。
作者从上述的三个方向进行验证评估：
对于R1方向，手工验证无假阳率，有4个cve -id在下一个主要版本中有未打补丁的代码，没有发现修补。
对于R2方向，手工检查，报告版本的精度也达到100%。
对于R3方向，在1367个cve - id中，337个存在部分匹配版本，其余1030个仅存在精确匹配版本。
对于仅精确匹配的1030个cve - id，检查了之前检查版本。其中，要么cve指定的文件不存在，要么源代码中没有脆弱函数(Fun)。因此，精确匹配方法下的𝑉𝑓𝑟𝑜𝑚没有假阴性。
对于部分匹配版本，有12个部分匹配版本，这使得研究无法判断是否存在漏洞。对应版本有74个，占337个cve的近3.6%。在剩余的325个cve中，如果有部分匹配码被我们的工具直接识别为漏洞，通过日志验证，发现有19个cve为假阳性，4个cve为假阴性，对应172个版本和39个版本。
误报的数量为172个版本，对应的真报的数量为4610个版本，该工具的正确率为96.4%。
在作者的数据集下，NVD误报告了11,827个版本，并且NVD很多第一个脆弱版本有很多误报，在1367个cve - id中，NVD上报的漏洞版本总数为43727个，其中误报2497个，误报9330个，分别占5.7%和21.34%。
作者是假设补丁是正确的情况下进行分析，倘若补丁不可用，该如何解决？
作者使用追踪日志的方法进行部分匹配，在人工核对是否脆弱，这一步是否可以用自然语言处理代替？
安全学术圈招募队友-ing
有兴趣加入学术圈的请联系 secdr#qq.com
