上周五，GoogleOpenSourceInsights团队在官方安全博客上发表了一篇文章，详细介绍了ApacheLog4j漏洞对行业的广泛影响。JamesWetter和NickyRingland指出，Maven的中央仓库有超过35,000个Java包，占总数的8%以上，它留下的隐患尤其让我们担心。（来自：谷歌安全博客）据了解，这些漏洞允许攻击者利用Log4j日志库众所周知的不安全JNDI查找功能来执行远程代码。不幸的是，许多版本默认启用此功能。Log4j漏洞自12月9日披露以来，因其严重性和广泛影响，引起了信息安全生态圈的高度关注。毕竟，作为一个流行的日志记录工具，它已经被数以万计的软件包（ArtifactsinJava）和项目所使用。由于用户对Log4j的传递依赖缺乏先见之明，这不仅使我们难以确定零日漏洞的范围，也使相关的修复工作变得相当困难。在此期间，GoogleOpenSourceInsights团队调查了Maven中央存储库中所有版本的Java工件，最终缩小到基于JVM语言的开源生态系统，同时密切跟踪发展。截至2021年12月16日，该团队从MavenCentral发现了35,863个依赖于受影响的log4j代码的Java工件。这意味着仅MavenCentral平台上就有超过8%的包至少有一个版本受此漏洞影响。从整个生态系统来看，漏洞的威力甚至更大（MavenCentral平均影响2%/中位数小于0.1%）。直接受影响的依赖项占这些工件的大约7000个，这意味着它们的任何版本都受到Log4j-core或Log4j-api的影响（完整列表请参阅CVE漏洞披露公告）。此外，大多数受影响的工件来自间接依赖项，即它们作为传递依赖项被引入。至于目前开源JVM生态的修复进度，如果至少有一个版本的神器受到影响，并发布一个不受漏洞影响的更稳定的版本，GoogleOpenSourceInsights团队将视为修复。例如，受Log4j漏洞影响的工件已经更新到2.16.0，或者完全去除了对Log4j的依赖。值得庆幸的是，Log4j维护者和更广泛的开源社区已经相当迅速地响应了这个问题，并且付出了巨大的努力。截至本博文发布时，该团队统计了将近5,000个固定项目。至于剩下的三万件神器，很多都依赖于另外一件神器。在传递依赖关系固定之前，只有一种尺寸适合所有人停止。对于Java生态来说，修复的难点主要体现在工件的互联互通上。首先，依赖链越深，修复bug所需的步骤就越多（超过80%的包都不止一层深）。其次，依托于算法和需求规范中的生态层级选择协议，也为此次活动埋下了不小的伏笔。在Java生态系统中，开发人员通常的做法是根据软件版本指定“软”需求（假设同一个包的其他版本没有出现在依赖图中）。此类修复通常需要维护者采取更明确的操作来更新补丁版本的依赖性要求。这种方法与其他生态系统形成鲜明对比，例如npm包，在其他生态系统中，开发人员通常会为依赖项指定开放范围。最后，很难评估整个生态系统修复错误需要多少时间。查看所有公开披露的影响Maven包的关键建议，我们发现只有不到一半(48%)得到修复。不过，Log4j方面的情况非常积极。不到一周后，修复了4620个受影响的工件（约13%）。剩下的工作还需要全球开源维护者、信息安全团队和用户的共同努力。
