谷歌开源洞察团队详解Apache Log4j漏洞造成的广泛影响

谷歌开源洞察团队详解Apache Log4j漏洞造成的广泛影响

上周五,谷歌开源洞察团队在官方安全博客上发表了一篇文章,详细介绍了 Apache Log4j 漏洞对行业造成的广泛影响。James Wetter 和 Nicky Ringland 指出,超过 35000 个 Java 包、占总数 8% 以上的 Maven 中央存储库,尤其让我们对其留下的隐患感到担忧。

谷歌开源洞察团队详解Apache Log4j漏洞造成的广泛影响

(来自:Google Security Blog)

据悉,这些漏洞允许攻击者利用 Log4j 日志库已被广为人知的不安全 JNDI 查找功能来执行远程代码。糟糕的是,这项功能在许多版本中都被默认启用。

自 12 月 9 日披露以来,Log4j 漏洞因其严重性和广泛影响,而引起了信息安全生态系统的高度关注。毕竟作为一款流行的日志工具,它已被数以万计的软件包(Java 里的 Artifacts)和项目所使用。

由于用户对 Log4j 的传递依赖项缺乏足够的远见,这不仅使得我们很难确定零日漏洞的影响范围、相关修复工作也变得相当困难。

谷歌开源洞察团队详解Apache Log4j漏洞造成的广泛影响

期间,Google 开源洞察团队调查了 Maven 中央存储库中的 Java 工件的所有版本,最终将范围缩小到了基于 JVM 语言的开源生态系统,同时密切追踪事态的发展。

截至 2021 年 12 月 16 日,该团队发现来自 Maven Central 的 35863 个可用 Java 工件,有依赖于受影响的 log4j 代码。

这意味着,仅 Maven Central 平台上超过 8% 的软件包,都至少有一个版本受此漏洞的影响。

若放眼整个生态系统,漏洞威力更是不容小觑(Maven Central 的平均影响为 2% / 中位数低于 0.1%)。

直接受影响的依赖项,约占这部分工件中的 7000 个,意味着它们的任何版本都被 Log4j-core 或 Log4j-api 所波及(完整列表可见 CVE 漏洞披露公告)。

此外大多数受影响的工件,都来自间接的依赖项,即它们是作为传递依赖项而被牵扯进来的。

谷歌开源洞察团队详解Apache Log4j漏洞造成的广泛影响

至于当前开源 JVM 生态系统的修复进展,若工件中至少有一个版本受到了影响,且发布了一个不受漏洞波及的更稳定版本,谷歌开源洞察团队就将之视作已修复。

比如受 Log4j 漏洞影响的工件已更新到 2.16.0、或完全剔除了对 Log4j 的依赖。庆幸的是,Log4j 维护者和更广泛的开源社区对此问题的响应是相当迅速的,并且付出了切实的巨大努力。

截止博客发表时,团队统计到了将近 5000 个已被修复的项目。至于剩余的那 30000 个工件,其中许多依赖于另一个工件。在传递依赖被修复前,暂时只有一刀切来阻止。

谷歌开源洞察团队详解Apache Log4j漏洞造成的广泛影响

对于 Java 生态系统来说,修复难度主要体现在工件的互相连接。首先,依赖链越深,漏洞修复所需的步骤就越繁杂(超过 80% 软件包的深度都超过了一级)。

其次,依赖算法和需求规范中的生态系统级选择约定,也为事件埋下了较大的伏笔。在 Java 生态系统中,开发者的通常做法是指定软件版本方面的“软”要求(假设没有其它版本的相同包出现在依赖关系图中)。

此类修复通常需要维护人员采取更加明确的行动,以将依赖需求更新为修补后的版本。这种做法与其它生态系统形成了鲜明的对比,例如在 npm 软件包上,开发者通常会为依赖项指定敞开的范围。

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

不过在 Log4j 方面,事情还算是相当积极的。不到一周后,就有 4620 个受影响的工件(约 13%)得到了修复。剩下的工作,仍需全球开源维护者、信息安全团队和广大用户付出巨大的努力。

未经允许不得转载:VPS服务器 » 谷歌开源洞察团队详解Apache Log4j漏洞造成的广泛影响

分享到: 生成海报