Log4j 1: How to mitigate the vulnerability in log4j without updating version to 2.15.0

Question

I am using Log4j 1.2.16. I am using this with a Maven Selenium testing Java project. I am looking for a solution without upgrading the version of Log4j.

<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>1.2.16</version>
</dependency>

Answer 1

Another answer is not correct. There is also a vulnerability for version 1.x. 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.

For the mitigation of this vulnerability:

These are the possible mitigations for this flaw for releases version 1.x:

• Comment out or remove JMSAppender in the Log4j configuration if it is used

• Remove the JMSAppender class from the classpath. For example:

  zip -q -d log4j-*.jar org/apache/log4j/net/JMSAppender.class
  

• Restrict access for the OS user on the platform running the application to prevent modifying the Log4j configuration by the attacker.

Answer 2

Since you're using Log4j 1, the specific vulnerability is not present there. However, note the following from Comments on the log4shell(CVE-2021-44228) vulnerability:

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.