Lessons from Log4Shell

Jun 09, 2022

As vulnerabilities go, Log4Shell (CVE-2021-44228) is by far the most critical software since OpenSSL Heartbleed, and the most far-ranging since the Meltdown and Spectre family of hardware vulnerabilities. Log4Shell is a zero-day remote code execution vulnerability found in a commonly deployed Java automated runtime events logging library, Log4j 2. As its name implies, it allows an attacker to execute code remotely from another device. The CVSS severity rating of Log4Shell is critical, meaning exploitation is relatively straight forward and granting root-level control, allowing the attacker to read or infiltrate sensitive information, or make any system changes they desire

The library provides a logging function, is popular with developers as it doesn’t interact with the main application, and is known for its versatility, allowing developers to specify what type of information are to be collected in the logs. It is also open source, which means developers can leverage without license infringement in their application development without restrictions, provided any modifications/improvements are also made available to the community.

Whilst the vulnerability has been present in the affected library since 2013, it was only discovered at the end of 2021 by Chen Zhaojun, from Alibaba. The library has been integrated into many products by different vendors, a full list of which can be found here, which explains the community response. The prevalence of the vulnerability is due to three main reasons:

  • Java is the workhorse of web based and IoT systems
  • Logs are ubiquitous amongst applications regardless of the coding language. And the Java library in question is amongst the most popular logging libraries for Java developers
  • The vulnerability can be exploited easily, Apache assigned the highest CVSS rating of 10, for a critical vulnerability

A misconception for commercial software is that they consist of 100% bespoke code where the IPR and functionality are associated with the organisation that produced them. With the exception of niche use cases, the use of entirely bespoke code is not usually a viable proposition in commercial software. Indeed, the vast majority of code and functionality in commercial applications are from open-source libraries. Thus, the discovery and remediation of vulnerabilities are community efforts.

It is customary for vulnerabilities to be disclosed privately (in this instance, to the Apache Software Foundation) before a public disclosure. The process is designed to provide to product vendors and software producers a head-start on remediation measures due to the speed at which exploits are released once vulnerabilities are known. Nevertheless, end users (and/or system managers) also need to be ready. With the exception of Software-as-a-Service offerings, the following steps will help organisations to protect themselves, their customers and associated third parties:

  • Maintain an up-to-date inventory of existing assets, including software versions (often known as a Software Bill of Materials, or SBOM)
  • An effective vulnerability management and response programme
  • Agile and responsive patch management processes, which is particularly important for large organisations that are often more “bureaucratic”
  • Defined compensating controls when remediation through patching is not feasible
  • Proactive review of applications, systems and infrastructure for vulnerabilities and exploits

As Heartbleed, and more recently, Log4Shell showed, software development is a community affair. Open-source libraries are used for functionality, this means many applications, particularly those in the same industry will share snippets of code. Attackers know this, which partly explains why they have been so successful. Fortunately, defenders will have access to the same vulnerability and exploit information that can be leveraged to protect their organisations. This is perhaps the most valuable lesson from Log4Shell and a successful security programme.

Dr. Wendy Ng is a DevSecOps Security Managing Advisor, who’s honed her technical consulting skills through a number of industries: aerospace, healthcare, fintech, telco, transport logistics, and critical national infrastructure. Wendy completed her doctoral studies at the University of Oxford and has contributed to the scientific community through peer-reviewed publications. She has been sharing her experience and expertise, addressing key challenges, in her blogs since 2016.