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 family||Is it affected?||Is there a fix available?|
|Puppet||Continuous Delivery for Puppet Enterprise is affected||44228 fix available|
|Jenkins||Jenkins Core is not affected, preliminary list of affected plugins is available||–|
|GitLab||No||44228 fix available|
|GitHub||GitHub Enterprise Server is affected||44228 fix available|
|JetBrains||Hub, YouTrack Standalone, YouTrack InCloud, Code with me, JetBrains Account, Floating license server, and Upsource are affected||44228 fixes are available, though additional steps need to be taken|
|Eclipse||Passage project and Eclipse IDE for RCP and RAP Developers which contain Passage are affected||workarounds|
|Spring Boot||Depending on set logging system||fix will be part of Dec 23 update|
|Docker||No (a list of official images that might be affected along with mitigation help is available in the announcement blog)||–|
|Red Hat||Red 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 affected||depending on project, mostly not|
|Databricks||No (recommended mitigation steps for customer code are available)||–|
|VMware||Large parts of the portfolio are affected||patches are currently pending but some workarounds are available|
|Elastic||Older versions of Elasticsearch, APM Java Agent depending on configuration, and Logstash are affected||44228 fixes and mitigation tips are available|
|Apache Software Foundation||Apache Archiva,Calcite Avatica, Druid, EventMesh, Flink, Fortress, Geode, Hive, Jena, JMeter, JSPWiki, Log4j 2.x, OFBiz, Ozone, SkyWalking, Solr, Struts, and TrafficControl are affected||depending on project|