In this advisory, we will address the core facts regarding the recently disclosed security vulnerability in the Apache log4j project, which has been dubbed “Log4Shell”, why it’s important to address quickly, how to address it, and how to better prepare for future vulnerabilities.
What is the Log4Shell vulnerability?
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."
Why is the Log4Shell vulnerability so important?
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."
How should my organization respond?
(Updated 14 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.6.10 and later or 2.12.2.
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.
How can my organization prepare for issues like this in the future and how can Tidelift help?
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.
The Tidelift Subscription can help you quickly identify if the affected component is in use and where.
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.
If you’d like to learn more about the Tidelift approach to managing open source:
- Take a tour of the Tidelift Subscription and watch our demo video
- Try the Tidelift Subscription for free and get an open source software bill of materials for your application that can tell you whether you are using log4j today
- Watch our recent product update and live demo of the Tidelift Subscription
- Join our upcoming webinar about open source software supply chain security
- Watch our recent webinar with Jim Mercer from IDC about best practices for safely building enterprise applications with open source
50 Milk St, 16th Floor, Boston, MA 02109
.svg){kind=icon}