The Log4j vulnerability and its impact on software supply chain security

Editor's note (28 Dec 2021 at 7:35 p.m. GMT): The Log4j team released a new security update that found 2.17.0 to be vulnerable to remote code execution, identified by CVE-2021-44832. We recommend upgrading to the latest version, which at this time is 2.17.1. Read more here.

Editor's note (18 Dec 2021 at 6:55 p.m. GMT): The Log4j situation is rapidly changing and we are updating our blogs as new information becomes available. It is recommended you upgrade to version 2.17.1 or later. This version contains security fixes for two remote code execution vulnerabilities, fixed in 2.15.0 (CVE-2021-44228) and 2.16.0 (CVE-2021-45046) and the latest DoS vulnerability fixed in 2.17.1 (CVE-2021-45105). Read more here.

By now, you already know of — and are probably in the midst of remediating — the vulnerability that has come to be known as Log4Shell and identified as CVE-2021-44228. This is the vulnerability which security researchers disclosed on Friday (10 December 2021) for Apache’s Log4j logging framework.

In this article, we’ll explore a few key Log4j facts as well as actions you can take to protect yourself and your company:

• Log4j is a critical vulnerability that requires urgent action

• Log4j is widely used and will have a massive impact

• Log4j has a substantial impact on supply chain security and will be difficult to fix

• Prioritizing the Log4j security fix amongst an already cluttered security backlog is critical

• Responding quickly to critical issues like Log4j is key to the business

Log4j is a critical vulnerability that requires urgent action

We can’t stress enough how important this Log4j vulnerability is. It’s a critical security vulnerability with a CVSS score of 10 (the highest score possible) that allows attackers to execute code remotely in any vulnerable environment. This is a big deal and requires urgent action to fix.

Please read the sections below outlining what immediate action you should take based on which versions of Log4j you’re currently using in your application(s).

I am using Log4j v1, what should I do?

The risk here is greatly diminished in comparison to the 2.x affecting vulnerability, however, under very specific circumstances, Log4j v1 allows for lookups, similar to what we have seen impacting log4j2, which do not protect against LDAP or other endpoints resolved via JNDI. These attack vectors (and potentially others) are known to lead to remote code execution (RCE) attacks. If you are using a version of the Log4j v1 which has enabled JMSAppender, there is a chance that you could be vulnerable. It is important to note that JMSAppender is disabled by default and as such is unlikely to be enabled in most instances of Log4j v1 used in applications.

This is a critical, recent update that was only been rolled out recently (13 December 2021 at ~5PM UTC) and is tracked by Snyk using the vulnerability ID SNYK-JAVA-LOG4J-2316893.

As such, we’re recommending that if possible you upgrade to the latest v2 version of Log4j which includes the recent vulnerability fix. You should consult Apache’s official Migration from Log4j v1 document. If you are unable to upgrade, you should look to disable JMSAppender or block any user input from reaching its configuration.

I am using Log4j v2, what should I do?

If you’re using Log4j version 2.x, you should upgrade to the latest Log4j v2 release (currently 2.16.0) that remediates the vulnerability.

I am using Log4j v1 or v2 but I can’t quickly upgrade, is there an immediate workaround?

Where upgrading is not possible in the immediate future, you should read our Log4j article that explains how to remediate the vulnerability by setting system properties and Java parameters.

Log4j is widely used and will have a massive impact

Logging is commonplace

When building applications, developers almost always log data in order to have information for debugging, analytics, and auditing purposes. In addition to the usefulness of logs for everyday development purposes, many security teams also demand logging in order to provide audit trails that can be used to track and correlate potential suspicious activity.

Logging is an essential development practice

The fact that logging is so ubiquitous and that the Log4j vulnerability can be triggered by logging user input severely increases the attack’s severity and widens the potential attack vectors. For example, it has been publicly observed over social media that users have begun using Log4j exploit payloads as their email addresses and usernames in web forms.

While we won’t know the full impact of the Log4j vulnerability for a while, since the publication of the vulnerability there have already been reports of hundreds of attempts to exploit this vulnerability in the wild by both seemingly opportunistic attacks and more sophisticated botnets.

The Log4j open source library is widely used

As you might imagine from the popularity of this vulnerability, Log4j is extensively used across vendors, open source projects, frameworks and top-level foundation projects.

In addition to the millions of Java applications using Log4j, many of the Apache Software Foundation’s own projects are making use of Log4j themselves, such as Apache Solr, Apache Struts2, Apache Kafka, Apache Druid, Apache Flink, Apache Swift and others.

It’s also being widely used by many other popular projects such as: Redis, Elasticsearch, Spring Framework, Netty, and more.

Even the National Security Agency (NSA) reverse engineering tool Ghidra, which was released as an open source project to the public, has been found vulnerable to this Log4j security issue.

Vendors as a whole have also been largely impacted by this vulnerability, including AWS’s own AWS CloudHSM, Amazon OpenSearch, and potentially other service products. It also extends to RedHat products such as Red Hat JBoss Fuse 7, Red Hat CodeReady Studio 12, Red Hat OpenShift Logging and more. As you can imagine, many other vendors such as VMware, Cisco, and others are very much affected by this.

We have found that within Snyk’s own user base, there’s also a significant impact. About 1/3 of Snyk customers are impacted by the Log4j vulnerability, which accounts for tens of thousands of vulnerabilities that we’ve detected across projects imported or monitored by Snyk.

The third-party open source crisis revolving around the Log4j Java library further strengthens the need to keep track of software bill of material (SBOM) across the organization and integrate a software composition analysis tool that allows your development and security teams to respond quickly.

Log4j has a substantial impact on supply chain security and will be difficult to fix

By leveraging our data of projects imported, monitored, and scanned by Snyk, we have been able to gain a deep insight into usage patterns of the Log4j library across projects.

To date, we’ve found that 60% of the Java projects we’re monitoring at Snyk that are using the Log4j library are using it as an indirect dependency. Indirect dependencies are those which a project uses indirectly (a.k.a. one of your project’s dependencies uses Log4j, thereby making you vulnerable even though you aren’t using Log4j yourself). This means that a straightforward search to determine if you’re using a vulnerable version of Log4j is not necessarily going to find all occurrences of the library in your projects and you will need a software composition analysis (SCA) tool, like Snyk, to be able to recurse through a deeply nested dependency graph and correlate versions with a vulnerability database to determine supply chain security risks.

In fact, in Snyk’s State of Open Source Security Report from 2020, we learned about (and confirmed!) that most vulnerabilities originate from indirect dependencies in the Java, Ruby, and JavaScript ecosystems:

This is one of the many reasons why, as a developer, you need to use security tooling like Snyk to help identify vulnerabilities in your projects (like log4j): simply knowing whether or not you’re using a vulnerable dependency isn’t enough: you also need to recursively know whether your dependencies are vulnerable as well.

All of this is to say that fixing the new Log4j vulnerability will be tricky as many open source libraries will need to be upgraded to fix the issue so that any projects relying on them will no longer be vulnerable. And this will take some time.

The Log4j vulnerability poses an imminent, global threat. Similar to how the COVID-19 pandemic has hit us and required worldwide health organizations and medical research companies to collaborate and work together, we’re witnessing that similar collaboration is currently taking place and is sorely needed in order to address the overall risk that stems from the Log4j vulnerability and to provide a holistic resolution for the community.

Prioritizing the Log4j security fix amongst an already cluttered security backlog is critical

For many, the Log4j vulnerability is yet another urgent security issue that needs to be addressed amongst an already cluttered backlog of security debt.

With growing security vulnerabilities across language ecosystems, misconfigurations, operating system open source components, and other application security concerns, how do security teams know where to start? What is the most important and urgent security vulnerability they need to attend to when they are already understaffed?

Prioritization is not only a key factor to how security teams work effectively, but also a significant tool in reducing overall business risk. In order to be effective, security teams need the ability to understand the risk of security vulnerabilities, not just for one project, but as a holistic view of the entire organization.

To allow developers and security teams to respond promptly and assess security risks from an overall organizational perspective, we introduced the concept of Priority Scores into Snyk.

Whereas traditional security practices have relied upon the CVSS factor of a security vulnerability, which mostly lacked context, Snyk’s priority score factors in contextual information about a security vulnerability such as taking into account the exploit maturity status, social trends, the assigned CVE severity score, whether there’s a fix available, and whether it was recently disclosed.

Our priority score ranges from 0, the lowest score, to 1000, the highest score possible and represents the most urgent security vulnerabilities a business needs to address. The Log4j security vulnerability is the perfect example which showcases how our priority score allows teams to correctly prioritize the fix. Below is an image from the Snyk dashboard showing how, in some cases, it scored the specific Log4j CVE as the highest possible score of 1000 across thousands of vulnerabilities that an organization has to deal with across hundreds of projects spanning different ecosystems and languages:

Guy Podjarny (Snyk’s Founder and President) further iterated on this concept and explained the difference between important and urgent, and how that applies to security prioritization. In fact, we have further extended this concept to cloud native application development to allow teams more insights with contextual prioritization in their Kubernetes deployments.

Responding quickly to critical issues like Log4j is key to the business

The Log4j vulnerability has rushed incident response teams to identify root causes and begin scanning through (and remediating) their inventory of deployed Java applications.

There’s no doubt that incident response teams needed to respond fast to critical vulnerabilities like  Log4j, but this burden also extends to developers and appsec teams who take on the responsibility of their application’s security.

Snyk’s core DNA is focused on developer-first and developer-friendly security. To be able to allow developers and security teams to find and fix security vulnerabilities as quickly and as effortlessly as possible is not just a primary goal for us, it’s what we’re all about.

Throughout the security chaos of addressing the Log4j vulnerability, we were delighted and humbled to see others finding success with Snyk in remediating the vulnerability:

It’s not only about proactively and automatically fixing vulnerabilities for developers, but also about being able to account for security issues across all of your source code repositories — including those dusty old legacy projects:

Your next steps for remediating Log4Shell

There is a light at the end of this tunnel — you just have to take some steps towards it!

Snyk can help out in various ways, from understanding the level of exposure across your different applications, through testing early and across your SDLC, to triggering automated fix pull requests to quickly fix vulnerabilities identified.

We highly recommend you read up on how to find and fix Log4Shell quickly with Snyk for practical advice on quickly fixing Log4j related vulnerabilities across your projects. If you haven’t already, sign up for Snyk — it’s free!

With events still unfolding, it’s always a good idea to stay on top of the news. We will continue to roll out updates via our newsletter and this blog so stay tuned!

And to end on a lighter note, at least this critical vulnerability has resulted in some familiar chuckles. The old “Little Bobby Tables” XKCD comic comes to mind (with some new modifications, as was originally shared on social media):