原文作者:Chengwei Liu, Sen Chen, Lingling Fan, Bihuan Chen, Yang Liu, Xin Peng
原文标题:Demystifying the Vulnerability Propagation and Its Evolution via Dependency Trees in the NPM Ecosystem
原文链接:https://arxiv.org/pdf/2201.03981.pdf
原文来源:CSE 2022
笔记作者:[email protected]
文章小编:[email protected]
NPM上发布了170多万个Node.js库,以促进软件开发。正如对比安全所揭示的,第三方库出现在当今软件的大多数(79%)中。然而,任何事物都有两面性。虽然使用库可以减少开发成本和时间,但这些集成库在实践中对软件生态系统构成了新的安全威胁,这些库中的漏洞可能会使依赖它们的软件不断面临安全风险。之前的工作已经调查了整个NPM生态系统的脆弱性影响,而他们的方法要么只是静态地考虑直接依赖性,或者基于依赖关系进行间接依赖的可达性分析,这可能会引入不准确的传递依赖关系,从而导致误报漏洞警告。现存的研究方法还没有提供一个精确的依赖关系。尤其是软件依赖关系之间的内部复杂关系,在很大程度上削弱了其分析的影响,并限制了进一步的解决方案(即精确修复)的提出。尽管一些现有的SCA工具(如Snyk和Blackduck)支持对用户项目进行NPM依赖性分析,但大多数工具都是从实际安装中检索依赖树,而不是从静态推理中检索依赖树。此外,由于语义版本控制的灵活性,依赖关系以及依赖关系中的漏洞实际上会随着时间的推移而发生动态变化。因此,尽管现有工作也调查了漏洞的影响,在没有静态和精确的依赖关系解决方案的情况下,大规模分析依赖关系中存在的漏洞传播的演变仍然是一个挑战,更不用说在防止漏洞动态引入依赖项方面获得实用的解决方案。
包括依赖漏洞知识图构建、依赖树解析、漏洞路径识别及其验证、大规模实证研究以及对经验教训和解决方案的讨论,以及可能的研究方向
为了支持高精度和高效率的大规模依赖漏洞分析,我们设计并实现了一套数据处理平台,以构建和维护完整而精确的依赖漏洞图DVGraph(基于neo4j)。
下图为改数据处理平台的框架:
Metadata Pipeline:将数据保存在元数据库中
CVE Pipeline:从NVD数据集收集CVE数据
CVE Triage Pipeline:手工标记CVE数据的对应的受影响的库和版本
Graph Pipeline:解析新来的元数据和映射的CVE数据,计算要在DVGraph上执行的操作(即添加、更改和删除节点和边),并最终执行这些操作
目前还没有一个考虑到特定于平台的依赖关系解决规则,可能导致不准确的依赖关系解析。本文目标是实现静态解析与NPM在实际安装过程中动态解析和安装的依赖树一致的依赖树,以便我们能够准确有效地识别依赖树中的漏洞和脆弱路径,而无需实际安装。
为了提高精度,同时保持效率,我们提出了一种基于DVGraph的依赖解析算法(DTResolver),可以在不安装的情况下,对任意数据软件包依赖解析的过程中,识别并找出所有依赖中含有安全漏洞的组件及相应的依赖引入路径
此外由于NPM中广泛使用依赖约束条件(版本范围)而不是固定版本进行依赖定义,导致依赖安装结果随着时间可能发生变化
如下图中,在[email protected]发布后,[email protected]的安装过程中,对B的依赖将解析成新发布的版本而不是原有的[email protected], 图中[email protected]的发布亦是如此。因此我们在DTResolver的基础上进一步增加了时间约束,使其能够支持在给定项目从其发布前到DVGraph更新时间内任意时刻的依赖树模拟解析。
给出了脆弱点和路径的示例 通过反向深度优先搜索(DFS)实现了一个脆弱路径提取器,以彻底查找依赖树中从脆弱点到根节点的依赖关系
以下两个方面分析NPM中安全漏洞的影响:
首先,依赖关系中的漏洞可能永远不会影响根包,因为可能永远无法访问这些易受攻击的功能。这只能通过基于依赖树和调用图分析易受攻击的函数调用路径来进一步解决。我们将此作为我们未来的工作。其次,CVE和库版本的映射是手动标记的,这可能会导致数据错误标记,合作的作者已将数据与现有CVE交叉验证,以缓解此类威胁。第三,我们无法区分包含缺失依赖项的安装,这可能会使基本事实不准确,我们只接受依赖项中成功安装的包作为验证中的基本事实。第四,由于计算成本过高,在分析漏洞传播时,我们忽略了具有超过1k条漏洞路径的版本。总的来说,这样的版本只占2.01%,这只能对我们的结果造成有限的偏差。
安全学术圈招募队友-ing
有兴趣加入学术圈的请联系 secdr#qq.com