首页 > 其他分享> > log4j的bug演示与修复

log4j的bug演示与修复

2021-12-26 10:02:20 作者：互联网

1. 描述

在 Apache Log4j2 版本（最高包括 2.14.1）（不包括安全发布版 2.3.1、2.12.2 和 2.12.3）中，在配置、日志消息和参数中使用的 JNDI 功能部件不能抵御攻击者控制的 LDAP 和其他 JNDI 相关的端点的攻击。启用消息查找替换后，能够控制日志消息或日志消息参数的攻击者可以执行从 LDAP 服务器加载的任意代码。从 2.0-beta9 到 2.14.1 的所有版本皆收到影响。

2. Log4j版本详细信息

从 Log4j 2.15.0 开始，默认情况下禁用消息查找功能。配置中的查找仍然有效。虽然 Log4j 2.15.0 有一个选项可以以这种方式启用查找，但强烈建议用户不要启用它。为 JNDI 连接引入了白名单机制，缺省情况下只允许本地主机。发现 2.15.0 版本存在其他漏洞，因此不建议使用。

从版本 2.16.0（对于 Java 8）开始，消息查找功能已完全删除。配置中的查找仍然有效。此外，Log4j 现在缺省情况下会禁用对 JNDI 的访问。现在需要显式启用配置中的 JNDI 查找。建议用户不要在 Log4j 2.16.0 中启用 JNDI，因为它仍然允许 LDAP 连接。如果需要 JMS 追加器，请使用以下版本之一：2.3.1、2.12.2、2.12.3 或 2.17.0：从这些版本开始，JNDI 连接中仅支持 JAVA 协议。

从版本 2.12.2（对于 Java 7）和 2.3.1（对于 Java 6），消息查找功能已被完全删除。配置中的查找仍然有效。此外，Log4j 现在缺省情况下会禁用对 JNDI 的访问。现在需要显式启用配置中的 JNDI 查找。启用后，JNDI 将仅支持 JAVA 协议，对 LDAP 协议的支持已被删除。

从版本 2.17.0（对于 Java 8）开始，对 LDAP 协议的支持已被删除，并且 JNDI 连接中仅支持 JAVA 协议。

从版本 2.17.0（对于 Java 8）、2.12.3（对于 Java 7）和 2.3.1（对于 Java 6），启用 JNDI 的属性已从 'log4j2.enableJndi' 重命名为三个单独的属性："log4j2.enableJndiLookup"、"log4j2.enableJndiJms"和 "log4j2.enableJndiContextSelector"。

3. Log4j官网发布的缓解措施

1、 Log4j 1.x缓解措施

Log4j 1.x没有查找，因此风险较低。使用 Log4j 1.x 的应用程序仅在其配置中使用 JNDI 时才容易受到此攻击。已针对此漏洞提交了一个单独的 CVE （CVE-2021-4104）。缓解措施：审核日志记录配置，以确保它没有配置 JMSAppender。没有 JMSAppender 的 Log4j 1.x 配置不受此漏洞的影响。

2、 Log4j 2.x缓解措施

实现以下缓解技术之一：

升级到 Log4j 2.3.1（适用于 Java 6）、2.12.3（适用于 Java 7）或 2.17.0（适用于 Java 8 及更高版本）。
否则，在 2.16.0 以外的任何发行版中，您可以从类路径中删除 JndiLookup 类：zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class。

请注意，只有 log4j-core JAR 文件受此漏洞影响。仅使用 log4j-api JAR 文件而不使用 log4j-core JAR 文件的应用程序不受此漏洞的影响。

另请注意，Apache Log4j 是唯一受此漏洞影响的日志记录服务子项目。其他项目，如Log4net和Log4cxx不受此影响。

3、不可信的缓解措施

在2.15.0版本中，当配置有包含上下文查找的模块（例如，$${ctx：loginId}）时仍然容易受到攻击。当攻击者可以控制线程上下文时，他们可能会注入JNDI Lookup模块，该模块将导致 JNDI 连接。虽然 Log4j 2.15.0 尽最大努力尝试将 JNDI 连接限制在本地，但仍有一些方法可以绕过此操作，用户不应依赖此连接。

为此提出了新的 CVE（CVE-2021-45046）。

缓解措施包括：对于 >= 2.10 的版本，将系统属性 log4j2.formatMsgNoLookups 或环境变量 LOG4J_FORMAT_MSG_NO_LOOKUPS 设置为 true;对于 >= 2.7 和 <= 2.14.1 的版本，将修改日志记录配置以禁用使用 %m{nolookups}、%msg{nolookups} 或 %message{nolookups} 进行消息查找。

这些措施不足的原因是，除了上面提到的线程上下文攻击媒介之外，Log4j中仍然存在可能发生消息查找的代码路径：已知示例是使用Logger.printf（"%s"，userInput）的应用程序，或者使用自定义消息工厂的应用程序，其中生成的消息不实现StringBuilderFormattable。可能还有其他攻击媒介。

最安全的做法是将 Log4j 升级到安全版本，或者从 log4j-core jar 中删除 JndiLookup 类。

4. Spring官网发布的log4j2的漏洞缓解措施

Log4J2漏洞可以允许攻击者远程执行代码。该漏洞已在Log4J -core jar中使用CVE-2021-44228报告，并已在Log4J v2.15.0中修复。

Spring Boot用户只有在将默认日志系统切换到Log4J2时才会受到此漏洞的影响。在spring-boot-starter-logging中包含的log4j-to-slf4j和log4j-api jar不能单独使用。只有使用log4j-core并在日志消息中包含用户输入的应用程序才容易受到攻击。

即将发布的v2.5.8和v2.6.2版本(2021年12月23日发布)将采用Log4J v2.17.0，但由于这是一个如此严重的漏洞，如果需要覆盖Spring的依赖管理，并尽快升级Log4J2依赖。Spring提供了以下缓解措施。

4、 Gradle

对于Gradle用户，可以按照下面的说明更新version属性，导入BOM或者使用aresolutionStrategy。