All hands on deck: Log4j team rethinks defaults to help prevent Log4Shell – how to know if it affects you

The team behind Java logging framework Log4j has reworked the standard behaviour of its project slightly and made the changes available in version 2.16. An update is strongly recommended, as the adjustments take additional steps to prevent setups from being susceptible to critical severity vulnerability CVE-2021-44228 and newly discovered CVE-2021-45046.

Why all of this?

On December 6, the Apache Log4j project released version 2.15 of the framework, which included a fix to protect users against attacker-controlled LDAP and other endpoints related to the Java Naming and Directory Interface (JNDI). The issue was publicly disclosed three days later, and is present in versions 2.0-beta9 to 2.14.1 — so projects still on Log4j 1.x are mostly off the hook. It entails that “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.”

Since Log4j can be used to log anything from chat messages to user credentials, and lookup is often enabled by default, gaining “control” over the log message can be as easy as feeding the system a carefully crafted input through those openly available interfaces. An attack is therefore comparatively simple to perform but can provide malicious actors with complete control over an application — which is why CVE-2021-44228 has been scored with the highest CVSS of 10.0.

Combine this with the fact that Log4j is pretty widespread in the world of Java — both through direct use and common project dependencies (think Flink, Struts, and Solr) users tend to forget about — and you might get an idea why the issue is on the minds of operations teams everywhere.

And things don’t seem to stop. Teams just discovered that the first fixes proved “incomplete in certain non-default configurations”, culminating in the disclosure of new vulnerability CVE-2021-45046 — which Log4j 2.16 is supposed to fix by removing message lookups and disables JNDI functionality by default.

What to do now?

Java developers using Log4j directly are advised to update their setup to use version 2.16 of the logging framework in order to stay safe.

It’s the hidden dependencies that make things a little bit more tricky. Hence the current flood of blog entries from tool vendors, project maintainers, and service providers trying to clarify if users need to take action. Checking the respective resources for your specific toolset or deployment platform is a good starting point to ensure your setup’s safety. Security scanners are already starting to add checks for container workloads, so looking at those closely would be a good idea as well, if you’re working with containerised apps and are uncertain if any of your dependencies use log4j.

To give you a rough idea about the state of your setup, we’ve compiled a list of commonly used tools and their current security status in regards to CVE-2021-44228 and CVE-2021-45046 below.