Log4j - How to protect my application?

Updated:

Marco Molteni

This is a quick note about the solutions for the Log4j vulnerability that ‘surprised the world’. You can find more details on Wikipedia here.

Are you using Spring Boot?

If you are using Spring Boot you should be safe if you didn’t change the out of the box configuration. Spring Boot doesn’t use log4j-core (the implementation with the bug).

The blog of spring.io has more details here: https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot.

You should be concerned only if you modified the default configuration or you are using some old versions of Spring Boot not more maintained. In this case I recommend to verify the library used and to read the comments of the readers of the Spring blog. Many developers found some issues / solutions with old Spring Boot versions.

You can find more details in the deep dive below.

Update Log4j to 2.17 (not 2.15 or 2.16)

If you are using the implementation of Log4j (log4j-core) and not only the API, the best solution is to update Log4j to the latest version, currently version 2.17.0.
The version 2.15.0 corrected the vulnerability but some issues were still present and 2 other releases were made quickly available, the 2.16.0 removes the messages lookup feature and disables access to JNDI by default fixing a bug that allows a Denial of Service attack (https://www.cve.org/CVERecord?id=CVE-2021-45046).

The 2.17.0 add the protection against uncontrolled recursion from self-referential lookups (https://logging.apache.org/log4j/2.x/security.html, CVE-2021-45105) should be considered as the minimal to use.

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

You can find the binary version here.

Launch option

If you cannot update the library yet but you can change the options of the application you can launch it with:

-Dlog4j2.formatMsgNoLookups=true example java -Dlog4j2.formatMsgNoLookups=true -jar mySuperApp.jar

This option works only with version >= 2.10.0. You can find more details about the feature here:Add property to disable message pattern converter lookups

Remove JndiLookup from the classpath

Here an example of solution zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. The command has to be adapted to your environment.

Tools

Log4j-detector Detects Log4J versions on your file-system within any application that are vulnerable to CVE-2021-44228 and CVE-2021-45046.

Log4Shell impacted software This page contains an overview of any related software regarding the Log4j vulnerability. On this page NCSC-NL will maintain a list of all known vulnerable and not vulnerable software.

Deep dive: log4j and Spring Boot

In the official documentation for Spring Boot is written that Spring Boot uses Common Logging as default logger and Logback if you are using a Spring starter (default for almost every web project).

In the following image you can see the libraries used in a simple Spring Boot project version 2.4.3.

In the orange rectangle Spring uses the log4j-api-2.13.3 ... don't be misled ... the issue is in the implementation of log4j the log4j-core package that is not used by Spring. Spring uses the logback-classic implementation of log4j as you can see in the green rectangle.

The communication between the log4j-api and the logback-classic implementation is allowed by the sl4j-api in the blue rectangle that act as façade between the different frameworks.

Here you can find the documentation for sl4j-api: https://www.slf4j.org and here the website of logback http://logback.qos.ch.

Log4j in Spring Boot?

To be at risk your project must have overridden the default configuration of Spring including the required log4j implementation in the classpath (log4j-core), excluded the logback implementation or forced the use of a different logging library (org.springframework.boot.logging.LoggingSystem) and provided the log4j configuration file (log4j2-spring.xml or log4j2.xml).

Example in maven for a project that uses Starters:

<dependency> 
	<groupId>org.springframework.boot</groupId> 
	<artifactId>spring-boot-starter-web</artifactId> 
</dependency> 
<dependency> 
	<groupId>org.springframework.boot</groupId> 
	<artifactId>spring-boot-starter</artifactId> 
	<exclusions> 
		<exclusion> 
			<groupId>org.springframework.boot</groupId> 
			<artifactId>spring-boot-starter-logging</artifactId> 
		</exclusion> 
	</exclusions> 
</dependency> 
<dependency> 
	<groupId>org.springframework.boot</groupId> 
	<artifactId>spring-boot-starter-log4j2</artifactId> 
</dependency>

You can find a log4j configuration file here.

In conclusion, if some developer didn’t play too much with the standard configuration and you are not working on some legacy project, your project should not be affected by this vulnerability.

Deep dive: Logback update

Following the issue with Log4J related to JNDI lookup, Logback released a new version of his library (1.2.9) to increase the security level of the same. Logback is the library used by Spring Boot by default.

You have more details here: http://logback.qos.ch/news.html

The same attack that works for Log4j doesn’t work with logback, the update of the library should not be required for the vast majority of the projects. The attackers requires the writing access to logback.xml to succeed exploit the JNDI weakness. If an external attacker can write one of your configuration files I guess that is not Logback the main issue. I think that most of the project can simply wait the update of Spring Boot to automatically upgrade the library.