Grails Framework and Log4j 2 Vulnerability

By Sergio del Amo

December 14, 2021

Vulnerability CVE-2021-44228 may allow an attacker to remotely execute code. It affects Log4j's log4j-core jar. Log4j v2.15.0 fixes it. Moreover, Log4j v2.16.0 disables JNDI functionality by default, and it removes message lookups. Log4j v2.17.0 addresses CVE-2021-45105. It protects against infinite recursion in lookup evaluation.

Are Grails 2 applications vulnerable?

CVE-2021-44228 only affects log4j versions between 2.0 and 2.14.1. Grails 2 applications used Log4j 1.x. However, you should consider migrating as soon as possible to the latest version of the Grails framework. Grails 2 is EOL (End of Life).

Are Grails applications (3, 4, or 5) vulnerable?

All Grails applications built on Grails framework 3.0.0 and later use Logback. Thus, most Grails applications are not affected.

However, your application might be vulnerable if it includes untrusted input in the log messages and pulls log4j-core as a transitive dependency through some other library or a plugin.

The "tomcat-embed-logging-log4j" dependency

You might have noticed that there is a tomcat-embed-logging-log4j dependency in the classpath. We believe it is not affected by the vulnerability because:

1. The JAR does not contain org/apache/logging/log4j/core/lookup/JndiLookup.class.
2. The POM does not mention any dependencies.

How can you check to see if you are pulling log4j-core as a transitive dependency?

If you are using Gradle, the following command will return a dependency report for 'log4j-core' dependency:

./gradlew dependencyInsight --dependency log4j-core

For Grails 2 applications, use:

./grailsw dependencyReport

How do you tell your build to use a particular version of Log4j?

With Gradle, if your application is pulling log4j-core transitively, you can declare a resolutionStrategy:

configurations.all {
  resolutionStrategy.eachDependency { DependencyResolveDetails details ->
    if (details.requested.group == 'org.apache.logging.log4j') {
      details.useVersion '2.17.0'
    }
  }
}

Other Options

If you cannot upgrade, please do the following, as suggested by the Log4j team:

For those who cannot upgrade to 2.15.0, in releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases >=2.7 and <=2.14.1, all PatternLayoutpatterns can be modified to specify the message converter as %m{nolookups} instead of just %m. For releases >=2.0-beta9 and <=2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

Learn More

All Grails applications built on Grails framework 3.0.0 and later are Spring Boot applications. Learn more about Log4j 2 vulnerability and Spring Boot in the Spring blog.

You might also like ...