Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

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

I am using log4j 1.2.16. I am using this with maven selenium testng 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>
over 4 years ago · Santiago Trujillo
2 answers
Answer question

0

Since you're using log4j 1, the 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.

over 4 years ago · Santiago Trujillo Report

0

The other answer is not correct. There is also a vulnerability for Version 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.

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.
over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!