Log4j 1：如何在不更新版本到 2.15.0 的情况下缓解 log4j 中的漏洞
Log4j 1: How to mitigate the vulnerability in log4j without updating version to 2.15.0
我正在使用 log4j 1.2.16。我在 maven selenium testng java 项目中使用它。我正在寻找不升级log4j版本的解决方案
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.16</version>
</dependency>
由于您使用的是 log4j 1，specific vulnerability is not present there. However, note the following from http://slf4j.org/log4shell.html:
Is log4j 1.x vulnerable?
Given that log4j version 1.x is still very widely deployed, perhaps 10 times more widely than log4j 2.x, we have been receiving a steady stream of questions regarding the vulnerability of log4j version 1.x.
As log4j 1.x does NOT offer a JNDI look up mechanism at the message level, it does NOT suffer from CVE-2021-44228.
However, log4j 1.x comes with JMSAppender which will perform a JNDI lookup if enabled in log4j's configuration file, i.e. log4j.properties or log4j.xml.
An attacker who ALREADY has write access the log4j configuration file will need to add JMSAppender into the configuration poisoned with malicious connection parameters. Note that prior legitimate usage of JMSAppender is irrelevant to the ability of the attacker to mount a successful attack.
Also note that poisoning the configuration file is not enough. The attacker also needs to force log4j to reload its configuration file with the poisoned parameters. Given that log4j 1.x does not offer automatic reloading, the poisoned configuration file will typically only become effective at application restart.
Nevertheless, while not easy, such an attack is not impossible. Thus it makes some sense to make job of the attacker even harder by removing JMSAppender altogether from log4j-1.2.17.jar.
In the absence of a new log4j 1.x release, you can remove JMSAppender from the log4j-1.2.17.jar artifact yourself. Here is the command:
zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class
If you do not have access to 'zip', you can also use the 'jar' command.
#assuming log4j-1.2.17.jar exists in current directory
mkdir tmp
cd tmp
jar xvf ../log4j-1.2.17.jar
rm org/apache/log4j/net/JMSAppender.class
jar cvf ../log4j-1.2.17-patched.jar .
It goes without saying that once log4j-1.2.17.jar is patched, you would need to deploy it.
其他答案不正确。版本 1.x 也存在漏洞。 CVE-2021-4104 https://access.redhat.com/security/cve/CVE-2021-4104:
A flaw was found in the Java logging library Apache Log4j in version 1.x. JMSAppender in Log4j 1.x is vulnerable to deserialization of untrusted data. This allows a remote attacker to execute code on the server if the deployed application is configured to use JMSAppender and to the attacker's JMS Broker.
对于此漏洞的缓解：
这些是针对发布版本 1.x 的此缺陷的可能缓解措施：
- 如果使用了 Log4j 配置中的 JMSAppender，请注释掉或删除它
- 从 class 路径中删除 JMSAppender class。例如：
zip -q -d log4j-*.jar org/apache/log4j/net/JMSAppender.class
- 限制 OS 用户在平台上的访问 运行 应用程序以防止攻击者修改 Log4j 配置。
我正在使用 log4j 1.2.16。我在 maven selenium testng java 项目中使用它。我正在寻找不升级log4j版本的解决方案
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.16</version>
</dependency>
由于您使用的是 log4j 1，specific vulnerability is not present there. However, note the following from http://slf4j.org/log4shell.html:
Is log4j 1.x vulnerable? Given that log4j version 1.x is still very widely deployed, perhaps 10 times more widely than log4j 2.x, we have been receiving a steady stream of questions regarding the vulnerability of log4j version 1.x.
As log4j 1.x does NOT offer a JNDI look up mechanism at the message level, it does NOT suffer from CVE-2021-44228.
However, log4j 1.x comes with
JMSAppenderwhich will perform a JNDI lookup if enabled in log4j's configuration file, i.e. log4j.properties or log4j.xml.An attacker who ALREADY has write access the log4j configuration file will need to add
JMSAppenderinto the configuration poisoned with malicious connection parameters. Note that prior legitimate usage ofJMSAppenderis irrelevant to the ability of the attacker to mount a successful attack.Also note that poisoning the configuration file is not enough. The attacker also needs to force log4j to reload its configuration file with the poisoned parameters. Given that log4j 1.x does not offer automatic reloading, the poisoned configuration file will typically only become effective at application restart.
Nevertheless, while not easy, such an attack is not impossible. Thus it makes some sense to make job of the attacker even harder by removing
JMSAppenderaltogether from log4j-1.2.17.jar.In the absence of a new log4j 1.x release, you can remove
JMSAppenderfrom the log4j-1.2.17.jar artifact yourself. Here is the command:zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.classIf you do not have access to 'zip', you can also use the 'jar' command.
#assuming log4j-1.2.17.jar exists in current directory mkdir tmp cd tmp jar xvf ../log4j-1.2.17.jar rm org/apache/log4j/net/JMSAppender.class jar cvf ../log4j-1.2.17-patched.jar .It goes without saying that once log4j-1.2.17.jar is patched, you would need to deploy it.
其他答案不正确。版本 1.x 也存在漏洞。 CVE-2021-4104 https://access.redhat.com/security/cve/CVE-2021-4104:
A flaw was found in the Java logging library Apache Log4j in version 1.x. JMSAppender in Log4j 1.x is vulnerable to deserialization of untrusted data. This allows a remote attacker to execute code on the server if the deployed application is configured to use JMSAppender and to the attacker's JMS Broker.
对于此漏洞的缓解：
这些是针对发布版本 1.x 的此缺陷的可能缓解措施：
- 如果使用了 Log4j 配置中的 JMSAppender，请注释掉或删除它
- 从 class 路径中删除 JMSAppender class。例如：
zip -q -d log4j-*.jar org/apache/log4j/net/JMSAppender.class
- 限制 OS 用户在平台上的访问 运行 应用程序以防止攻击者修改 Log4j 配置。