<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=705633339897683&amp;ev=PageView&amp;noscript=1">

 

Log4Shell: The Log4j vulnerability resource center

News, perspectives, and recommendations for application development teams dealing with Log4Shell, the Log4j vulnerability.

Log4Shell critical vulnerability: what you need to know and do

In this resource center, 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.

read the advisory

Log4j vulnerability resource center.

 

"Our security team is currently assessing the scope of Log4j usage. They were able to use the OSS inventory report as a starting point. We are so fortunate to have a tool like Tidelift that gives us insight into OSS usage across [the org]."
- Current customer

Tidelift's response to Log4Shell

  • Tidelift internal security alert created December 9
  • Catalog tasks created for customers December 9, allowing customers to identify every application using Log4j, immediately
  • Customer outreach starting December 10, before CVE created
  • Vulnerability guidance on upgrade path and mitigation procedures
  • Vulnerability updated with CVE ID once issued
  • Proactive outreach to all customers using the Log4j library

Learn more

Frequently asked questions

What is Log4j?

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. 

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. 

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...

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...

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 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...

(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.

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...

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.

Why this should matter to every organization:

Screen Shot 2022-01-14 at 1.20.58 PM

 

From Heartbleed to Log4Shell: How are things better? How are they the same?

If you work in an organization that uses open source to develop applications, by now you are probably aware of the recently disclosed vulnerability in log4j, commonly being referred to as the Log4Shell vulnerability.

Tidelift solutions architect lead Mark Galpin shares insights into theLog4Shell vulnerability and discusses how things have changed since Heartbleed, a similar zero day vulnerability from a decade ago. He shares how things have improved and discusses ways we can continue addressing the underlying issues even better. He shows how Tidelift can help with these challenges.

WATCH NOW

For years, experts have been telling the government to take stock of the software supply chain by generating software bills of materials and defining standards and policies for use.

In this Upstream chat, Tracy Bannon from MITRE  and Tidelift CEO and co-founder Donald Fischer discuss risk profile and ways organizations can force-rank priorities and how it applies to open source software specifically.

Donald and Tracy also discuss 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. You won't want to miss this.

WATCH NOW

Tracy Bannon from MITRE  and Tidelift CEO and co-founder Donald Fischer discuss risk profile

Tidelift's Mark Galpin discusses the Log4Shell vulnerability

 

It has been a mad scramble over the last few weeks to understand the impact of the Log4Shell vulnerability (first identified on December 9th). While most organizations are busy applying fixes, as of December 14th, there already is a new Log4j related vulnerability being reported.

In this 20-minute briefing, Tidelift solutions architect lead Mark Galpin shares what you need to know about the recent Log4Shell vulnerability—and demos how Tidelift can help.

WATCH NOW

Tidelift wants to help your organization reduce security risk from bad open source packages

In this guide, you will learn:

  • How to employ a proactive approach to help eliminate risk often associated with "bad" open source packages
  • Why working with, and paying, open source maintainers is key to strengthening software supply chain security
  • How Tidelift partnered maintainers  used funding from Tidelift and its paying customers to improve the security and maintenance of their open source packages  

READ MORE

The Tidelift guide to reducing security risk from bad open source packages

 

FTC warns of legal action for failure to protect against open source vulnerabilities—here’s how you can minimize risk

Resources for dealing with the Log4Shell vulnerability: