共计 2193 个字符，预计需要花费 6 分钟才能阅读完成。
自 12 月 9 日 Apache Log4j 2“惊天破绽”被曝出后，寰球泛滥科技企业已受到其影响。12 月 17 日，谷歌方面发表已对该事件进行了考察，并于 12 月 21 日将后果颁布在了 Google cloud 官网页面上。
据 Google cloud 页面上 12 月 21 日颁布的考察结果显示：面向消费者和付费用户的 Google Workspace 外围服务没有应用 Log4j2，也没有受到 CVE-2021-44228 和 CVE-2021-45046“破绽”的影响。谷歌方面示意将为此平安征询提供工作区外围服务的具体状态。
谷歌方面示意，Google Cloud 正在积极关注开源 Apache“Log4j 2”实用程序（CVE-2021-44228 和 CVE-2021-45046）中的安全漏洞。他们曾经留神到了报告的 Apache“Log4j 1.x”破绽（CVE-2021-4104），并倡议用户更新到 Log4j2 的最新版本。
12 月 17 日，在 Google cloud 博客页面上，谷歌开源洞察小组（Open Source Insights Team）解释了他们察看到的对于 Apache Log4J 破绽的全副状况。他们形容了宽泛存在的破绽以及修复开源 JVM 生态系统的以后停顿。
随后，谷歌评估了该破绽对 Google cloud 产品和服务的潜在影响，并依据正在进行的调查结果，提供开源 Apache“Log4j 2”破绽对 Google cloud 产品和服务的潜在影响做实时更新。谷歌方面示意，这将是一个继续的流动，后续也将持续通过此页面和客户沟通渠道提供更新。
Apache Log4j 破绽的规模及产生的影响
据悉，此前披露的 Log4j 破绽共波及 35000 多个 Java 包，占 Maven 地方存储库的 8% 以上（存储库是最重要的 Java 包存储库，它为软件行业带来了宽泛的成绩）。专家指出，对于整个生态系统而言，8% 是一个较大的数值了，因为 Maven Central advisories 后果的均匀数值为 2%，中位数小于 0.1%。当然，下面提到的数字并未蕴含所有 Java 包（如间接散发的二进制文件）。
对此，谷歌 Open Source Insights Team 团队的专家们指出了妨碍修复过程的两个重要问题：
一、许多软件包间接依赖于 log4j。间接依赖项受影响软件约 7000 个，在此状况下，任何版本都依赖于 CVEs 中形容的受影响版本的 Log4j core 或 Log4j API（间接依赖或传递依赖是指自我依赖的依赖关系）。
所有依赖项的工作人员，在修复是否应用依赖项链查看时产生了重大阻碍：破绽陷得越深，修复它的步骤就越多。依据该团队的消费者依赖关系图，柱状图结果显示了大量的数据。超 80% 的软件包中，破绽的深度超过一级。在大多数状况下，受影响的级别降落了 5 级（有些甚至降落了 9 级）。修复的过程须要先到最深的依赖项，而后再到所有分支。
二、依赖解析算法和需要标准约定中的生态系统级抉择。这种做法不同于 npm，npm 通常为依赖需要指定凋谢范畴（凋谢范畴提供了抉择满足依赖性要求的最新公布版本的机会）。随后它又推出了新的修复计划，修补程序可用后，用户将在下一次生成时收到修补版本，能够更快地生成依赖项。
谷歌 Open Source Insights Team 团队示意，在 Java 生态系统中，通常的做法是指定“软”版本要求——若在依赖关系图中后面没有呈现同一包的其余版本，则解析算法应用的确切版本。流传修复通常须要保护人员采取明确的口头，将依赖项需要更新为修补版本。
有了以上这些，谷歌开源洞察团队（Open Source Insights Team）便倡议开源社区启用主动依赖项更新并增加平安缓解措施。他们还提供了 500 个受影响包的列表，其中一些包具备极高的可传递性。专家们认为，对这些包进行优先排序将有助于修复工作，并随后革除社区中的更多阻碍，并对那些降级了 Log4j 版本的开源保护人员和消费者表白了感激。
对于到底须要多长时间能力齐全修复所有问题，谷歌 Open Source Insights Team 团队也给出了本人的判断：很难晓得。如果所有影响 Maven 软件包的要害倡议都是公开披露的，那么这个过程可能须要一段时间。谷歌团队示意，受破绽影响的软件包中只有不到一半（48%）失去修复。但在 Log4j 方面，大概 13% 的问题已失去解决，前景应该是光明的。
事件回顾：
12 月 9 日，记录申请的罕用组件 Apache Log4j2 程序被曝出了一个破绽，该破绽可能使得运行 Apache Log4J2 版本 2.15 或以下的零碎受到侵害，并容许攻击者执行任意代码。
12 月 10 日，NIST 公布了一个要害的常见破绽和裸露警报——CVE-2021-4228：配置、日志音讯和参数中应用的 Java 命名目录接口（JNDI）性能无奈避免攻击者管制的 LDAP 和其余 JNDI 相干端点，即启用音讯查找替换时，能够管制日志音讯或日志音讯参数的攻击者能够执行从近程服务器加载的任意代码。
随后的几天，又被发现在 Apache Log4j 2.15.0 版本上存在敏感数据泄露的破绽，可用于从受影响的服务器下载数据，随后官网并倡议用户尽快降级到 2.16.0。
12 月 18 日，Apache Log4j 又被曝出 CVE-2021-45105 破绽 —— Apache Log4j 2.0-alpha1 到 2.16.0 的版本无奈避免自援用查找的不受控递归（Apache 官网已公布 2.17.0 版本修复）。
