几周前，有关 Log4j 安全问题的消息使网络上的许多用户颠倒了，这是被利用得最多的漏洞之一，许多专家将其标记为“网络中最危险的漏洞”。很长一段时间 », 在网络中已知的漏洞中，我们谈论其中的一些 在博客上 而这一次，我们又找到了另一个消息。
而且是前几天 发布消息称在Log4j 2库中发现了另一个漏洞 （已在 CVE-2021-45105 下列出）并且与前两个问题不同，它被归类为危险，但并不严重。
新问题 允许拒绝服务并以循环和异常终止的形式表现出来 处理某些行时。
脆弱性 影响使用上下文搜索的系统，例如 $ {ctx: var}, 确定日志输出格式。
该 Log4j 版本 2.0-alpha1 到 2.16.0 缺乏对不受控制的递归的保护什么 允许攻击者操纵替换中使用的值 导致无限循环，该循环将耗尽堆栈上的空间并导致进程挂起。 特别是在替换“${${::-${::-$${::-j}}}}”等值时出现问题。
另外， 可以注意到，Blumira 研究人员已经提出了针对易受攻击的 Java 应用程序的攻击 不接受来自外部网络的请求，例如 Java 应用程序的开发人员或用户的系统都可以通过这种方式受到攻击。
该方法的本质是如果存在易受攻击的Java进程 在仅接受来自本地主机 (localhost) 的网络连接或处理 RMI 请求（远程方法调用，端口 1099）的用户系统上， 攻击可以通过执行的 JavaScript 代码执行 当用户在浏览器中打开恶意页面时。 在这种攻击中，为了建立到Java应用程序的网络端口的连接，使用了WebSocket API，与HTTP请求不同，它没有应用同源限制（WebSocket也可以用于扫描本地网络端口主机以确定可用的网络驱动程序）。
评估与 Google 发布的 Log4j 依赖项相关的库的漏洞的结果也很有趣。 据谷歌称，这个问题影响了 Maven 中央存储库中 8% 的包。
特别是，35863 个具有直接和间接依赖关系的 Log4j 相关 Java 包暴露在漏洞中。 反过来，Log4j 仅在 17% 的情况下用作第一级的直接依赖，而在漏洞覆盖的包中，83% 的绑定是通过依赖于 Log4j 的中间包完成的，即tell。 第二级和最高级别的依赖关系（21% - 第二级，12% - 第三级，14% - 第四级，26% - 第五级，6% - 第六级）。
漏洞修复速度仍然有待改进，在发现漏洞一周后，在确定的 35863 个包中，目前仅修复了 4620 个，即 13% 的问题。
包更改是更新依赖项要求和用 Log4j 2 的固定版本替换旧版本绑定所必需的（Java 包练习绑定到特定版本，而不是允许安装最新版本的开放范围）。
消除 Java 应用程序中的漏洞受到以下事实的阻碍：程序通常在交付时包含库的副本，并且仅更新系统包中的 Log4j 2 版本是不够的。
与此同时，美国基础设施保护和网络安全局发布了一项紧急指令，要求联邦机构在 4 月 23 日之前识别受 LogXNUMXj 漏洞影响的信息系统并安装阻止问题的更新。
另一方面，在 28 月 23 日之前给出了一项指导方针，在该指导方针中，各组织有义务报告所开展的工作。 为简化问题系统的识别，编制了已确认存在漏洞表现的产品清单（清单中的应用程序超过XNUMX个）。
最后， 值得一提的是，该漏洞已在前几天发布的Log4j 2.17中修复 建议禁用更新的用户进行相应的更新，此外，由于该问题仅在使用 Java 8 的系统上出现，因此可以降低该漏洞的危险性。
数据来源： https://logging.apache.org/