Critical CVE-2021-44228 in Log4j - Check your application workloads!

Update 2021-12-16: The patched Log4j 2.15.0 was found to still have a possible vulnerability. We’ve updated the action below to update to (at least) version 2.16.0.

On Thursday the 9th of December a 0-day exploit in the popular Java logging library log4j2 was discovered, which can be used for Remote Code Execution (RCE) by logging a certain string. Dubbed Log4Shell, this CVE-2021-44228 has a CRITICAL severity.

Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (>2.10) this behavior can be mitigated by setting system property “log4j2.formatMsgNoLookups” to “true” or it can be mitigated in prior releases (<2.10) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

We have verified our managed platform components and determined they are not vulnerable (Apache Log4j2 is not used). For AWS services, you can follow this security bulletin: Update for Apache Log4j2 Issue (CVE-2021-44228). AWS systems that require manual intervention to apply the latest patches, have been updated (eg. Amazon OpenSearch / Elasticsearch Service).

While this covers the platform and managed service part, we strongly advise you to evaluate all application workloads you run, if you haven’t done so yet.

Actions to take

If you are using Log4j, you should update to 2.16.0 (or higher) immediately. If that is not possible, you should set the log4j2.formatMsgNoLookups=true JVM property (for releases >=2.10).

Mitigation: 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 from 2.7 through 2.14.1 all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m. For releases from 2.0-beta9 to 2.7, the only mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

Make sure to check out the resources below for more details and mitigation strategies!