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