上周五，Google开源系统洞悉精英团队在官方网安全性blog上刊登了一篇文章，详解了 Apache Log4j 漏洞对领域引起的普遍危害。James Wetter 和 Nicky Ringland 强调，超出 35000 个 Java 包、占数量 8% 以上的 Maven 中间储存库，特别是在使我们对其留有的安全隐患觉得忧虑。
(来源于：Google Security Blog)
据了解，这种漏洞容许网络攻击运用 Log4j 日志库已被广为流传的不安全 JNDI 搜索作用来实行远程控制编码。槽糕的是，此项作用在很多版本里都被默认设置开启。
自 12 月 9 日公布至今，Log4j 漏洞因其严重后果和普遍危害，而引发了网络信息安全生态系统的密切关注。终究做为一款时髦的日志专用工具，它已被数以万计的程序包(Java 里的 Artifacts)和工程所应用。
因为客户对 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 漏洞公布公示)。
除此之外大部分受影响的工件，都来源于间接性的依赖项，即他们是做为传送依赖项而被牵连进去的。
对于现阶段开源系统 JVM 生态系统的恢复进度，若工件中最少有一个版本遭受了危害，且公布了一个不会受到漏洞蔓延到的更平稳版本，Google开源系统洞悉精英团队就将之看作已修补。
例如受 Log4j 漏洞危害的工件已升级到 2.16.0、或彻底去除了对 Log4j 的依赖。幸运的是，Log4j 维护者和更普遍的开源项目对于此事问题的回应是非常快速的，而且投入了进一步的极大勤奋。
截至blog发布时，精英团队统计分析到了接近 5000 个已被修补的新项目。对于剩下的那 30000 个工件，在其中很多依赖于另一个工件。在传送依赖被修补前，临时仅有一刀切来阻拦。
针对 Java 生态系统而言，修补难度系数关键反映在工件的相互联接。最先，依赖链越重，漏洞修补需要的流程就越复杂(超出 80% 程序包的深层都超出了一级)。
次之，依赖优化算法和要求标准中的生态系统级挑选承诺，也为事情埋下了比较大的悬念。在 Java 生态系统中，开发人员的通常作法是特定手机软件版本层面的“软”规定(假定沒有其他版本的同样包发生在依赖关系图中)。
该类修补通常必须维护保养工作人员采用更为明晰的行为，以将依赖要求升级为修复后的版本。这类作法与其他生态系统产生了明显的比照，例如在 npm 程序包上，开发人员通常会为依赖项特定打开的范畴。
最终，针对全部生态系统必须消耗是多少的时间来进行漏洞修补，现阶段也难以评定。在查阅了全部公布透露的危害 Maven 包的重要提议中，大家发觉仅有不上一半(48%)获得了修补。
但是在 Log4j 层面，事儿还算得上非常积极主动的。不上一周后，就会有 4620 个受影响的工件(约 13%)获得了修补。剩余的工作中，仍需全世界开源系统维护者、网络信息安全精英团队和众多客户投入很大的勤奋。