Grails Framework and Log4j 2 Vulnerability
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:
- The JAR does not contain
org/apache/logging/log4j/core/lookup/JndiLookup.class
. - 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 variableLOG4J_FORMAT_MSG_NO_LOOKUPS
totrue
. For releases >=2.7 and <=2.14.1, allPatternLayoutpatterns
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 theJndiLookup
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.