Log4J 2.16.0 is Vulnerable to DoS. Upgrade to 2.17.0.

ALERT: 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.

Dear Java Developers, cancel your holiday plans. Another Log4j vulnerability was reported on December 16th Thursday and a new Log4j version is released with the patch on December 18th Saturday. Log4J 2.16.0 is no longer safe.

The new vulnerability independently discovered by Hideki Okamoto of Akamai Technologies, Guy Lederfein of Trend Micro Research working with Trend Micro’s Zero Day Initiative, and another anonymous vulnerability researcher allows denial of service attack on systems using Log4j 2.0-beta9 to 2.16.0. Remember that Log4j 2.16.0 was released last week to fix the CVE-2021-44228 vulnerability and chances are high for most of the Java projects already being upgraded to Log4j 2.16.0 which is vulnerable to DoS attack now.

Similar to the previous vulnerability, the CVE-2021-45105 doesn't mean everyone using Log4j 2.0-beta9 to 2.16.0 is vulnerable. This uncontrolled recursion from self-referential lookups bug affects only if your Log4j configuration has Context Lookups like ${ctx:loginId} or $${ctx:loginId}. Though removing such context lookups where they originate from sources external to the application such as HTTP headers or user input is one way to solve the issue, it is recommended to replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC). Instead, you can upgrade to the latest Log4j version 2.17.0.

Similar to CVE-2021-44228, CVE-2021-45105 also affects log4j-core only.

Last Friday, Google published a blog post claiming more than 35,000 Java packages in the Maven Central repository are affected by Log4j vulnerability. By the time of publishing that article only 5000 artifacts were patched. That leaves 30,000 packages hanging around with vulnerable Log4j dependency. Google also mentioned that in more than 80% of the packages, the vulnerability is more than one level deep, with a majority affected five levels down (and some as many as nine levels down). This makes fixing them hard as a package maintainer you have to rely on your dependency maintainer to publish a fixed version.

Coming to the projects you have control over, you have to go through the same cycle once more to upgrade all your Log4j dependencies to the latest version 2.17.0.

Let me repeat the process for developers to identify the vulnerable Log4J versions.

Run the following command from your project folder.

mvn dependency:tree

Any Log4J dependency with a version less than 2.17.0 is most likely vulnerable or unmaintained. Maven central repository has a new column with the number of vulnerabilities in each Log4j version.

If you encounter any vulnerable Log4j versions as your direct dependencies defined in your pom file, or in your parent pom file, upgrade them immediately. Remember by defining the following dependency in your pom file, you can override the dependency defined in your parent pom file.

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

 

Image Credits: Google

A vulnerable Log4J library can be buried under a multi-level dependency tree. If any of your libraries are using a vulnerable dependency, look for their latest fixed versions or talk to your security team.

• Twitter
• Facebook
• LinkedIn
• Tumblr
• Pinterest