Log4j 2 库中还发现了另一个漏洞 (CVE-2021-45105)，与前两个问题不同，该漏洞被归类为危险漏洞，但并不严重。 新问题允许您导致拒绝服务，并在处理某些行时以循环和崩溃的形式表现出来。 该漏洞已在几个小时前发布的 Log4j 2.17 版本中修复。 该问题仅出现在使用 Java 8 的系统上，这一事实减轻了该漏洞的危险。
该漏洞影响使用上下文查询（Context Lookup）（例如${ctx:var}）来确定日志输出格式的系统。 Log4j 版本从 2.0-alpha1 到 2.16.0 缺乏针对不受控制递归的保护，这使得攻击者可以操纵替换中使用的值来引发循环，从而导致堆栈空间耗尽和崩溃。 特别是在替换“${${::-${::-$${::-j}}}}”等值时出现问题。
此外，值得注意的是，Blumira 的研究人员提出了一种攻击不接受外部网络请求的易受攻击的 Java 应用程序的选项；例如，Java 应用程序的开发人员或用户的系统可以通过这种方式受到攻击。 该方法的本质是，如果用户系统上存在易受攻击的Java进程，仅接受来自本地主机的网络连接，或者处理RMI请求（远程方法调用，端口1099），则可以通过执行JavaScript代码来进行攻击当用户在浏览器中打开恶意页面时。 在此类攻击中，为了与 Java 应用程序的网络端口建立连接，需要使用 WebSocket API，与 HTTP 请求不同，WebSocket API 不受同源限制（WebSocket 还可以用于扫描本地网络端口）主机以确定可用的网络处理程序）。
同样令人感兴趣的是 Google 发布的评估与 Log4j 依赖项相关的库的漏洞的结果。 据 Google 称，该问题影响 Maven 中央存储库中所有软件包的 8%。 特别是，通过直接和间接依赖关系与 Log35863j 关联的 4 个 Java 包存在漏洞。 同时，Log4j 仅在 17% 的情况下被用作直接的一级依赖，而在 83% 的受影响包中，绑定是通过依赖于 Log4j 的中间包进行的，即第二级及以上的成瘾（21% - 第二级，12% - 第三级，14% - 第四级，26% - 第五级，6% - 第六级）。 修复漏洞的速度仍然有很多不足之处；漏洞被发现一周后，在 35863 个已识别的软件包中，迄今为止只有 4620 个软件包已修复该问题，即为 13%。
与此同时，美国网络安全和基础设施保护局发布了一项紧急指令，要求联邦机构识别受 Log4j 漏洞影响的信息系统，并在 23 月 28 日之前安装阻止该问题的更新。 23月XNUMX日之前，各组织必须报告其工作。 为了简化问题系统的识别，我们准备了一份已确认存在漏洞的产品列表（该列表包括超过 XNUMX 个应用程序）。
来源： opennet.ru