Log4j 1.x Vulnerability Mitigation Guide

Almost every day I see someone asking what to do about log4j 1.2 / 1.x versions. It can be quite a lot of wrap your head around, and it can't be answered easily in a sentence or two. So here's my attempt at providing some clarity and solutions for the millions of applications that are still using Log4j 1.x

TLDR: Apache Log4j 1.x does have vulnerabilities that are unpatched. Many configurations are not impacted by the vulnerabilities by default. Log4j 1.x is EOL so there are no fixed 1.x versions. You can patch the jar files yourself by removing the vulnerable class files. It's not a simple upgrade to go from Log4j 1.x to 2.x in most cases.

Current List of Log4j Security Vulnerabilities

As of December 28, 2021

java -classpath log4j.jar org.apache.log4j.net.SimpleSocketServer 4712 log4j-server.properties

Log4j 1.x Is No Longer Supported

The Apache Log4j 1.2 project page clearly states On August 5, 2015 the Logging Services Project Management Committee announced that Log4j 1.x had reached end of life... Users of Log4j 1 are recommended to upgrade to Apache Log4j 2.

The Log4j Project Maintainers have had their hands full with the issues in Log4j 2, and are understandably not at all interested in doing much to help log4j 1.x users. You'll have to either upgrade to Log4j 2, or get creative.

Is it easy to upgrade from Log4j 1 to Log4j 2?

No, it's not as simply as simply swapping out the jars unfortunately. If that were the case, we would probably have seen a lot more people using v2 that are still on v1.

The Log4j 1.2 Bridge

There is a log4j 1.2 bridge or adapter, which allows software written for Log4j 1.2 to use Log4j version 2 jars instead. I haven't investigated this fully yet, but it looks like for some software you might be able to use this to drop a bunch of jars in the right places. I'll post more info here after I investigate it more.

Checking log4j configuration for vulnerable Appenders

Log4j is very configurable, so you can configure it either from a configuration file, or at runtime. It is much harder to determine what appenders are being used at runtime (you need to review the source code). To review the configuration, search your file system for files containing log4j.appender or any of the following:

• SocketAppender
• SMTPAppender
• JMSAppender
• JDBCAppender
• log4j.appender.server
• log4j.appender.jms
• log4j.appender.email

The files may be either a properties file or an XML file, some common log4j configuration file names are:

• log4j.properties
• logger.properties
• logging.properties
• log4j.xml
• logger.xml
• logging.xml

If you were using the SocketAppender you might see a hit like this in a log4j.properties file:

log4j.appender.server=org.apache.log4j.net.SocketAppender

For the JMSAppender it might look like this:

log4j.appender.jms=org.apache.log4j.net.JMSAppender

And for the SMTPAppender like this:

log4j.appender.email=org.apache.log4j.net.SMTPAppender

Removing vulnerable classes from Log4j 1.x jars

In case you were not aware, a jar file is just a zip file, you can use any zip command to operate on them. For example using the command zip -d file.jar 'path/to/ClassName.class' you can remove a class from a jar file on Linux or a Mac.

Important: Make a backup of the jar files first before modifying them, and stop any running servers or java processes first.

To remove the JMSAppender class from a Log4j 1.2.17 jar:

zip -d log4j-1.2.17.jar 'org/apache/log4j/net/JMSAppender.class'

You will see output like this if it works:

deleting: org/apache/log4j/net/JMSAppender.class

If the jar path is incorrect, or it doesn't have the class you will see:

zip warning: name not matched: org/apache/log4j/net/JMSAppender.class

Or if you want to multiple vulnerable classes in one shot:

zip -d log4j.jar 'org/apache/log4j/net/JMSAppender.class' 'org/apache/log4j/net/SocketAppender.class' 'org/apache/log4j/net/SocketServer.class' 'org/apache/log4j/net/SMTPAppender$1.class' 'org/apache/log4j/net/SMTPAppender.class'

To make sure it worked, you can list the files contained in the jar file by running:

jar -tf log4j-1.2.17.jar

Or if you have unzip installed:

unzip -l log4j.jar

If possible, rename your jar file to something like log4j-1.2.17-patched-2021-12-20.jar so that it is more obvious that it was patched. Depending on how your java server or process starts, the jar file path may be in the classpath. Sometimes however all jar files in a directory are loaded into the classpath, so you can name it whatever you want, just be sure to remove the unpatched jars.

Now start your java server, or application again and test to make sure it still works.

Potentially Vulnerable Classes in Log4j 1.2

Here's a table listing the classes you might want to remove from a log4j 1.2 jar file:

DISCLAIMER: The content (and links) on this page are provided as is, without warranty of any kind. Use at your own risk. You should consult with your software vendors to ensure that you are properly protected.