CVE References

bkelly · ‎Jan 03, 2022

The following summary of Log4j is credited to Flexera Secunia Research's Lars Wiebusch

CVE References

CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-44832, CVE-2021-4104

Introduction

In December 2021, a vulnerability in Apache Log4j drew widespread attention as the product is widely used, vulnerability is easily exploitable and, in many cases, offers direct and indirect remote vectors. This vulnerability is referenced by the CVE identifier CVE-2021-44228 and was responsibly disclosed to the maintainer by Chen Zhaojun of Alibaba Cloud's security team.

It triggered an unprecedented run to analyze about every infrastructure imaginable. Software developers scrambled and still scramble to identify the effects of the Log4j vulnerability on their own products, right before and through a holiday season.

Of course, entities wanting to exploit the vulnerability quickly jumped into action as well and soon after the initial disclosure, first Proof of Concepts (PoCs) were detected being tested within live environments and subsequently exploitation campaigns made use of more refined attacks^[1].

This vulnerability disclosure also started further investigations through vulnerability researchers and Apache Log4j team members to see if further vulnerabilities exist and their search didn’t turn up empty: more issues came to light.

Apache Log4j Overview

The open-source project Apache Log4j is a logging package for the Java platform. What started with just basic logging functionality evolved into a framework that, among other features, can be expanded through plugins, custom layouts, filters, and lookups and offers audit capable logging (no loss of events during reconfiguration)^[2]. The current, supported version is based on the Java 8 platform since the 2.13.x branch. The previous branches were based on Java 6 and Java 7 respectively and are not supported by the maintainer of Apache Log4j anymore.

Such an amount of configurability and customizability can be used for great benefit in your own projects. However, one needs to be aware that such extensive functionality can also be more readily used against your own infrastructure through an attacker.

The Java platform, which is the base for the Apache Log4j project, comes with several security concerns on its own already. Deserialization and serialization vulnerabilities frequently show up in Java platform-based applications and its manifold capabilities to load and create Java classes on the fly and remotely can be easily used both in beneficial and nefarious contexts.

Vulnerability Details

The Beginning (Remote Code Execution, CVE-2021-44228, 2.x)

To have a look at how the vulnerability works, we must look at the Log4j functionality of lookups. Essentially, this functionality allows values to be added to the Log4j configuration^[3]. One part of the functionality allows JNDI lookups where multiple protocols are supported – one being LDAP. If an attacker can control parts of what gets logged, then arbitrary code might be downloaded from an attacker-controlled LDAP server (or other JNDI endpoints). The request for the download will be initiated from your own system. Such control is not uncommon, just think about servers logging User-Agent HTTP headers, user names or chat messages from chat interfaces.

A logged string may contain something like

and an attack will potentially go ahead.

This vulnerability affects Apache Log4j versions prior to 2.15.0 and can be referenced via the CVE identifier CVE-2021-44228.

Thread Context Map (Remote Code Execution, CVE-2021-45046, 2.x)

However, the fix for CVE-2021-44228 in version 2.15.0 was incomplete, which led to the acknowledgement of a further vulnerability that is exploitable in certain configuration scenarios^[4]. Essentially, exploitability relies on the use of a non-default Pattern Layout with a Context Lookup and where an attacker has control over Thread Context Map (MDC) input data.

Said variant received the additional CVE identifier CVE-2021-45046. This vulnerability has been fixed in version 2.16.0 of Apache Log4j.

Initially, the vulnerability was only expected to be exploitable to result in a Denial of Service (DoS) impact and was rated with a lower severity, but Apache revisited their analysis and admitted that arbitrary code execution is possible^[5].

Thread Context Map Part 2 (Denial of Service, CVE-2021-45105, 2.x)

The story could have ended there, but, unfortunately, a further vulnerability has been acknowledged shortly after^[6].

The vulnerability, associated with the CVE identifier CVE-2021-45105, has a lower impact, namely, its remote exploitation through Thread Context Map data results in a Denial of Service (DoS) condition solely. The issue results from an uncontrolled recursion when handling self-referential lookups and causes a stack overflow and process termination in the end.

The Apache Log4j team has released the version 2.17.0 to fix this CVE.

To note, there are also fixed version releases in the 2.3.x and 2.12.x branches even though the Apache Log4j team doesn’t support the Java 6 and Java 7 platforms anymore. Users of Log4j need to keep in mind, that such lack of support will result in unfixed security issues down the road and thus such an update cannot be recommended.

JDBC Appender (Limited Vector Code Execution, CVE-2021-44832, 2.x)

Just when we were about to prepare for the arrival of the new year, another issue with the CVE identifier CVE-2021-44832 has been acknowledged by the Apache Log4j team and was fixed in the 2.17.1 release^[7].

The use of the word ‘issue’ versus ‘vulnerability’ is intentional here as the issue requires an attacker to have the capabilities to modify a Log4j configuration to point the JDBC Appender to a malicious JNDI URI and thus hardly any real-world exploitation scenario seems imaginable when security best practices are being followed. In the case of remotely loading such configurations, the transfer must be adequately protected against Man-in-the-Middle (MitM) attacks for example. To call this issue a “Remote Code Execution (RCE) Vulnerability” appears to be a stretch with such requirements.

Again, the Apache Log4j team also released versions in the 2.3.x and 2.12.x branches without supporting these branches properly. These fixed releases cannot be seriously recommended due to lack of future support.

Apache Log4j End of Life Branch (Limited Vector Code Execution, CVE-2021-4104, 1.x)

Even the Log4j 1.x version branch, which is End of Life (EOL) though, could be exposed to an exploitation scenario like the original vulnerability in the 1.2 version.

However, similar to the JDBC Appender issue, the vector is severely more limited as any potential attacker needs to be able to modify the Log4j configuration^[8]. Typically, such write access will be restricted to privileged persons when following security best practices and thus will likely result in a lower risk from this specific variation of the vulnerability.

This variation affecting Apache Log4j versions 1.2.x can be referenced via the CVE identifier CVE-2021-4104. It is also typically referred to as “Log4Shell” even though the vectors and nature of the issue differ due to different feature sets of and implementation in Log4j when comparing the branches.

Everyone must keep in mind that using any product version that is EOL constitutes a large risk on its own as security issues won’t get fixed. The recommendation, as always, is to upgrade any EOL versions to a supported and secure product version.

Stay secure!

References

[1] https://blog.cloudflare.com/actual-cve-2021-44228-payloads-captured-in-the-wild/

[2] https://logging.apache.org/log4j/2.x/manual/index.html

[3] https://logging.apache.org/log4j/2.x/manual/lookups.html

[4] https://lists.apache.org/thread/83y7dx5xvn3h5290q1twn16tltolv88f

[5] https://logging.apache.org/log4j/2.x/security.html

[6] https://lists.apache.org/thread/6gxlmk0zo9qktz1dksmnq6j0fttfqgno

[7] https://lists.apache.org/thread/s1o5vlo78ypqxnzn6p8zf6t9shtq5143

[8] https://lists.apache.org/thread/0x4zvtq92yggdgvwfgsftqrj4xx5w0nx