Log4Shell: The Log4j vulnerability resource center

Apache Log4j is a Java-based logging utility originally written by Ceki Gülcü. It is part of the Apache Logging Services, a project of the Apache Software Foundation. Log4j is one of several Java logging frameworks. 

Log4j is one of the most ubiquitous libraries in modern applications, appearing in a vast number of packaged and custom applications. 

The Apache Foundation has released a critical vulnerability alert for log4j, a ubiquitous logging tool found in many Java applications. The vulnerability has been nicknamed Log4Shell and has been logged in the NVD as CVE-2021-44228:

"Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. 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." 

Virtually every organization using third-party software or developing custom applications with the Java programming language is potentially impacted.

Log4j is one of the most ubiquitous libraries in modern applications, appearing in a vast number of packaged and custom applications.  

According to data tracked by Tidelift, log4j-core has over 3,600 dependent packages in the Java language ecosystem and over 20,900 dependent software repositories on public code collaboration platforms. When looking across our customer base to do our outreach on the problem, we found that all of our customers with Java applications were using log4j and expect that this is generally the case outside of our customer base as well.

What makes this particular issue even more pernicious is, not only is log4j widely used, but this vulnerability is also incredibly easy for malicious actors to exploit. From the Wired article on the subject:

"All an attacker has to do to exploit the flaw is strategically send a malicious code string that eventually gets logged by Log4j version 2.0 or higher. The exploit lets an attacker load arbitrary Java code on a server, allowing them to take control."

(Updated 28 December 2021)

The initial CVE-2021-44228 was addressed in 2.15.0 and later versions but a new vulnerability (CVE-2021-45046) was discovered and is fixed in version 2.12.4 for Java 7 and 2.17.1  for Java 8+.

In addition to implementing immediate controls, organizations should immediately upgrade applications to incorporate a version of the log4j library that resolves the issue, and redeploy all production workloads, especially those that are public network-facing.

Organizations should be sure to comprehensively audit all of their software applications (both internally developed and vendor-provided). Many major vendors of all types of software products have begun posting information on how their products are impacted and providing mitigation paths specific to their products.

Unfortunately the previously suggested mitigation mechanisms have been shown to not completely reduce the risk and so an upgrade of the log4j is the recommended path forward at this point in time.

As an additional compensating measure, consider configuring Web Application Firewalls to block traffic seeking to exploit these vulnerabilities. For example, Cloudflare has described the WAF configurations they have put into place to defend their infrastructure and their customers.

Log4Shell is an important reminder that organizations need to have an accurate and up to date software bill of materials (SBOM) to help identify and track exactly which open source components are in use across the organization so that they can rapidly respond when serious issues arise.

In the case of Log4Shell, centrally managing a catalog of approved open source components using the Tidelift Subscription makes it easy for an organization to quickly identify if the affected component is in use and where, so remediation can be handled in a timely and comprehensive manner.

Tidelift customers were made aware of Log4Shell early, before a CVE had even been created. We recorded a vulnerability with guidance on the upgrade path and mitigation procedures that showed up as a Tidelift catalog task for customers to address. Once the CVE was issued, we updated our vulnerability report with the assigned CVE ID and proactively reached out to our customers with applications using the log4j library.

To better prepare to react quickly to vulnerabilities like this in the future, Tidelift recommends organizations implement a comprehensive and unified approach to managing the health and security of the open source software supply chain.