Log4j news – On 28th December 2021, another vulnerability affecting the Log4j logging library was discovered. The vulnerability is labelled CVE-2021-44832.
The vulnerability CVE-2021-44832 affects versions 2.17.0 and before. The vulnerability was assumed to be patched, but it wasn’t. The vulnerability shares similarity with CVE-2021-4104, which impacted the 1. x Log4j branch.
CVE-2021-44832 vulnerability scores a medium 6.6 on the CVSS scale and needs quite precarious pre-conditions for an attacker to take advantage of the vulnerability.
The vulnerability renders Log4j 2.17.0 (and earlier versions) susceptible to code execution if an attacker can control and alter the contents of the logging configuration file. The attacker needs to alter and control contents that allow a remote URI data source to load arbitrary Java code.
The patch in 2.17.1, and backported to older JVM-compatible versions of the library, mitigated that vulnerability by limiting the JNDI data source in the configuration file to only use the Java protocol and block any remote network calls.
The latest vulnerability has kept up with a negative trend of carelessly divulging vulnerabilities over the internet. The security researchers have disclosed the vulnerability details before maintainers have time to rectify the issue and release patches.
The trend has its root in the Log4j RCE, in which researchers leaked information and a proof of concept of the vulnerability on Twitter and GitHub. Again this vulnerability was made public through Twitter before the official release.
The disclosure about the vulnerability before the official release may be without malice, but it has led Apache to rush through with its patches, and it creates another opportunity for vulnerability. Additionally, in this specific instance we can assume that given a choice, Apache would have not chosen to rush out a release at a time of year where many organizations have extended holidays and would therefore be less able to quickly triage and remediate the issue if needed.