This project is intended to debunk two common misbeliefs regarding the impact of the recently discovered Log4j 2.x
vulnerabilities on Java applications, as reported by the following CVE records:
The first two, famously nicknamed Log4Shell, enable Remote-Code-Execution, while the last one allows a Denial-of-Service.
Misbelief #1: All Log4j modules from 2.0 to 2.16 were impacted by at least one of these vulnerabilities
Unfortunately, only the description of first CVE explicitly says that only the
log4j-core module was affected but the other two are vague on this impact.
The official Apache Log4j Security Vulnerabilities page,
more accurately states that only the
log4j-core was impacted by the 3 recent vulnerabilities.
Therefore, we can safely claim that:
Your application is immune to those three vulnerabilities if it does not include the
log4j-coremodule in the runtime classpath.
Misbelief #2: If log4-core older than 2.17 is present in the classpath, then my application is necessarily vulnerable
This one is more subtle. Many applications are based on Spring Boot that by default uses Logback as its logger, but also includes some Log4j modules to bridge the Log4J API to SLF4J/Logback, namely:
Not rarely, the
log4j-core can also be included on the runtime classpath indirectly by some application dependency.
On this scenario, fortunately, the Log4j LogManager won’t effectively use the
log4j-core module since this SLF4J bridge has higher priority. See the LogManager initialization code. Again, we can conclude that:
Your application is also immune if it contains both
log4j-corein the runtime classpath.
For all branches, we’re using the old, unpatched, Log4j v2.14.1.
How to run
First, build the application binary with:
$ ./gradlew installDist
Then run the application with no arguments to see the instructions: