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.
