都准备好了吗？没那么快。昨天，BleepingComputer 总结了迄今为止已知的所有 log4j 和 logback CVE。

自从上周开始出现关键的 log4j 零日漏洞以来，安全专家一次又一次地推荐版本 2.16 作为最安全的版本。

今天，随着 2.17.0 版本的发布，情况发生了变化，该版本修复了一个影响 log4j 2.16 的看似轻微但“高”严重性的拒绝服务 (DoS) 漏洞。

而且，是的，这个 DoS 错误带有另一个标识符：CVE-2021-45105。

无限递归，有限释放？

影响log4j的2.16.0一个拒绝服务漏洞的嫌疑Apache的JIRA项目出现了大约三天前，不久后2.15.0被认为是脆弱的未成年人拒绝服务漏洞（CVE-2021-45046）。

不过，正如 BleepingComputer 昨天报道的那样，Apache 将 CVE-2021-45046 的严重性从低 (3.7) 提高到严重 (9.0)，因为较新的绕过允许 通过此漏洞进行数据泄露的可能性。

“如果出于任何原因尝试对以下字符串进行字符串替换，它将触发无限递归，并且应用程序将崩溃，”使用 PoC 负载说明 JIRA 问题：

${${::-${::-$${::-j}}}}

几个小时前，包括vx-underground和Hacker Fantastic在内的安全研究人员在 推特上发布了一个可能影响 log4j 2.16 版的拒绝服务漏洞：
事实证明，在过去三天对该问题进行辩论后，Apache 确实分配了一个新的 CVE，并推出了一个新版本。

log4j 2.17.0 今天发布，修复了 DoS

被跟踪为 CVE-2021-45105，并在 CVSS 量表上得分为“高”（7.5），DoS 缺陷存在，因为 log4j 2.16“并不总是在查找评估中防止无限递归”。

尽管 JNDI 查找在 2.16 版中完全禁用，但在某些情况下仍然可以使用自引用查找。

“Apache Log4j2 版本 2.0-alpha1 到 2.16.0 没有防止自引用查找的不受控制的递归，”BleepingComputer 看到的版本发行说明说。

“当日志配置使用带有上下文查找的非默认模式布局（例如，${dollar}${dollar}{ctx:loginId}）时，攻击者可以控制线程上下文映射 (MDC) 输入data 可以制作包含递归查找的恶意输入数据，从而导致*Error终止进程。”

为了修复该漏洞，今天发布了log4j 版本 2.17.0（用于 Java 8），并且只允许“配置中的查找字符串”递归扩展。在任何其他用法中，只会解析*查找，而不是任何嵌套查找。

该版本预计将在今天晚些时候到达最大的 Java 包存储库 Maven Central。

尽管到目前为止 Apache 已经正式发布了即将发布的 2.17.0 版本的详细信息，但 BleepingComputer 看到的 GitHub 提交表明 2.12.3 版本也可能会在 2.12.x 分支版本上发布。

谷歌：超过 35,000 个 Java 包存在 Log4j 缺陷

谷歌的分析显示超过 35,000 个 Java 包包含 log4j 漏洞，这一发展与谷歌的分析同时进行。

“超过 35,000 个 Java 包，占 Maven *存储库（最重要的 Java 包存储库）的 8% 以上，受到最近披露的 log4j 漏洞的影响，”谷歌开源洞察团队的 James Wetter 和 Nicky Ringland 解释说。昨天的博文。

根据 Google 的说法，Maven Central 中的绝大多数易受攻击的 Java 包都是“间接”借用 log4j 的——即 log4j 是包所使用的依赖项的依赖项，这个概念也称为传递依赖项。

在谷歌识别的 35,863 个包中，只有大约 7,000 个直接借用了 log4j，这表明并非所有开发人员都可以充分了解他们的软件：

“用户对其依赖项和传递依赖项缺乏可见性，这使得修补变得困难；这也使得很难确定此漏洞的完整爆炸半径，”谷歌解释说。

纵观公开披露的影响 Maven 包的关键漏洞的历史，以及不到 48% 的包对这些漏洞进行了修复，谷歌研究人员预测，在所有 Java 中完全消除 log4j 缺陷之前“需要等待很长时间，可能需要数年时间”包。

正如 BleepingComputer 报道的那样，威胁行为者正在利用 log4j 漏洞攻击易受攻击的服务器来推送恶意软件，而 Conti 勒索软件团伙专门针对 易受攻击的 VMWare vCenter 服务器。

因此，组织应该升级到最新的 log4j 版本并继续监视 Apache 的更新建议。