How to Fix Log4J Vulnerability

ALERT 1: Log4J 2.16.0 is vulnerable to DoS attack. Switch to 2.17.0. For more details: Log4J 2.16.0 is Vulnerable to DoS. Switch to 2.17.0.


ALERT 2: Log4J 2.17.0 is vulnerable to RCE attack. Switch to 2.17.1. For more details: Log4J 2.17.0 is Vulnerable to RCE. Upgrade to 2.17.1.

 

Log4j security vulnerability has stolen the sleep of developers over the last week. Though it is a little late, this article explains how to identify if your project is using Log4j and how to fix the problem. Let's start with the problem description: In Apache Log4j2 versions up to and including 2.14.1 (excluding security release 2.12.2), the JNDI features used in configurations, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.

How to fix Log4J Vulnerability

 

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.


Though the Log4j you are using in your project is vulnerable doesn't mean that your project is vulnerable. If you are behind a firewall with no external access or if you don't log any user inputs, chances to attack your system are slim. However, it doesn't mean you can relax since it is always a best practice to fix vulnerabilities in the project regardless of whether you are affected or not.


Apache Log4j 1.x is only vulnerable to this attack if JNDI is enabled in the configuration. To make sure you are not affected with Log4j 1.x, audit your logging configuration to ensure it has no JMSAppender configured. Log4j 1.x configurations without JMSAppender are not impacted by this vulnerability. Those using Log4j 2.x with Java 8 or latest must upgrade to the latest release 2.16.0 and those using Log4j 2.x with Java 7 must upgrade to the 2.12.2 version.

 

Apache Community released 2.15.0 on Dec 10th, 2021 with the message lookups feature disabled by default but it is strongly advised to switch to 2.16.0 released on Dec 13th, 2021. From version 2.16.0 (for Java 8), the message lookups feature has been completely removed. Lookups in configuration still work. Furthermore, Log4j now disables access to JNDI by default. JNDI lookups in configuration now need to be enabled explicitly. Users are advised not to enable JNDI in Log4j 2.16.0. If the JMS Appender is required, use Log4j 2.12.2.


From version 2.12.2 (for Java 7), the message lookups feature has been completely removed. Lookups in configuration still work. Furthermore, Log4j now disables access to JNDI by default. JNDI lookups in configuration now need to be enabled explicitly. When enabled, JNDI will only support the java protocol.


Knowing the fix is the second step of solving the problem. The first step is identifying affected projects in your team or organization. The following section explains how to identify the affected projects using Apache Maven for dependency management.


Step 01:

Run the following command to check if log4j is being used in your project.

mvn dependency:tree | grep log4j


Step 02:

If you found log4j in the first step, run the mvn dependency:tree and analyze the output to find from where the log4j dependency is coming from.


It can be either a direct dependency on your project or it can be a dependency of your dependencies. For example, Apache Spark 3.0.1 is using Log4j 1.2.17 but if you are using Spark 3.0.1 there is nothing much you can do on your side. Instead, you have to wait for the Apache Spark team to release a new version if they think the current version is affected by this vulnerability.


If Log4j is defined in your pom.xml file, things are much easier. Upgrade the Log4j version based on your Java version and release a new version. However, if the Log4j dependency is inherited from the parent pom file, you may have to check with the team providing the parent pom file for an upgraded version or override the Log4j dependency in your pom file.

 

To override the Log4j dependency, simply add the following dependency in your pom.xml:

 

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.16.0</version>
</dependency>

 

After making the changes, run the following command again to make sure you have the latest Log4j version.

mvn dependency:tree | grep log4j

Previous
Next Post »

Contact Form

Name

Email *

Message *