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

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.

Tool/Product familyIs it affected?Is there a fix available?
PuppetContinuous Delivery for Puppet Enterprise is affected44228 fix available
JenkinsJenkins Core is not affected, preliminary list of affected plugins is available
GitLabNo44228 fix available
GitHubGitHub Enterprise Server is affected 44228 fix available
JetBrainsHub, YouTrack Standalone, YouTrack InCloud, Code with me, JetBrains Account, Floating license server, and Upsource are affected44228 fixes are available, though additional steps need to be taken
EclipsePassage project and Eclipse IDE for RCP and RAP Developers which contain Passage are affectedworkarounds
Spring BootDepending on set logging systemfix will be part of Dec 23 update
DockerNo (a list of official images that might be affected along with mitigation help is available in the announcement blog)
Red HatRed Hat CodeReady Studio 12, Red Hat OpenStack Platform 13, Red Hat Integration Camel K, Red Hat Integration Camel Quarkus, Red Hat OpenShift Application Runtimes Vert.X 4, Red Hat Fuse 7, Red Hat OpenShift 4, Red Hat OpenShift 3.11, Red Hat OpenShift Logging, Red Hat Data Grid 8, and Red Hat AMQ Streaming are affecteddepending on project, mostly not
DatabricksNo (recommended mitigation steps for customer code are available)
VMwareLarge parts of the portfolio are affectedpatches are currently pending but some workarounds are available
ElasticOlder versions of Elasticsearch, APM Java Agent depending on configuration, and Logstash are affected44228 fixes and mitigation tips are available
Apache Software FoundationApache Archiva,Calcite Avatica, Druid, EventMesh, Flink, Fortress, Geode, Hive, Jena, JMeter, JSPWiki, Log4j 2.x, OFBiz, Ozone, SkyWalking, Solr, Struts, and TrafficControl are affecteddepending on project