文 | 局长

来自 Google Open Source Insights Team 的安全研究人员通过调查 Maven Central 中所有软件包的所有版本,以更好地了解最近曝出的 Log4j 漏洞对整个 JVM 语言生态系统的影响,同时还跟踪了正在进行的缓解受影响软件包的工作。

研究人员发现,截至 2021 年 12 月 16 日,来自 Maven Central 的 35,863 个可用软件包依赖于存在漏洞的 log4j 代码。这意味着 Maven Central 上超过 8% 的软件包至少有一个版本受漏洞影响(此数字不包括所有 Java 软件包,例如直接分发的二进制文件)

就生态系统影响而言,8% 是相当巨大的数字。因为对 Maven Central 生态的平均影响数值为 2%,中位数则低于 0.1%。

如记录漏洞的 CVE 所述,大多数受影响的软件包来自间接依赖项(即自身依赖项的依赖项),也就是说它们没有将 log4j 明确定义为依赖项,而是作为传递依赖项被引入进来。

这正是 JVM 生态整体上修复此漏洞异常困难的原因。安全研究人员称,在撰写文章时,只修复了近五千个受影响的软件包,还有 30000 多个软件包会受到漏洞的影响。

简单来说就是,漏洞在依赖关系链中嵌套得越深,修复漏洞所需的步骤就越多。下图显示了受影响的 log4j 包(核心或 api)首次出现在依赖图中的深度的直方图。对于超过 80% 的软件包,该漏洞的深度超过一级,其中大多数受影响的级别下降了 5 个级别(有些甚至下降了 9 个级别)。这些包将需要在依赖树的所有部分进行修复,而且首先从最深处的依赖关系开始。

修复漏洞的另一个困难之处由解析算法 (resolution algorithm) 和需求规范约定中生态系统层级的选择引起。

在 Java 生态中,开发者通常的做法是指定软件版本方面的“软”要求——假设没有其它版本的相同包出现在依赖关系图中,解析算法会使用指定的明确版本。对于此类修复,通常需要维护者采取更加明确的行动,以将依赖需求更新为修补后的版本。这种做法与其它生态形成了鲜明的对比,例如在 npm 软件包中,开发者通常会为依赖项指定开放范围。开放范围允许解析算法选择满足依赖性要求的最近发布的版本,从而引入新的修复。

最后,对于整个生态需要耗费多少时间来完成漏洞修复,目前也很难评估。在查看了所有公开披露的受影响 Maven 软件包中,安全人员发现只有不到一半(48%)得到了修复。

声明:本文来自OSC开源社区,版权归作者所有。文章内容仅代表作者独立观点,不代表安全内参立场,转载目的在于传递更多信息。如有侵权,请联系 anquanneican@163.com。