Another security vulnerability impacting the Log4j logging library was published as CVE-2021-44832. This new security vulnerability is affecting versions up to 2.17.0, which was previously thought to be fixed. This vulnerability is similar in nature to CVE-2021-4104 which affected the 1.x branch of Log4j.
CVE-2021-44832 vulnerability has been assigned a medium 6.6 CVSS score and requires considerably elevated pre-conditions for an attacker to exploit successfully.
It deems Log4j 2.17.0 (and older versions) to be vulnerable to code execution if an attacker is able to control, and modify, the contents of the logging configuration file to then point to a remote URI data source to load arbitrary Java code.
The fix in 2.17.1, and back ported to older Jvm-compatible versions of the library, mitigated that vulnerability by restricting the JNDI data source in the configuration file to only allow the use of the Java protocol, and disallow any remote network calls to be made.
The Log4j team published fixes for this security vulnerability:
- If you’re on Java 8 and later you should upgrade to Log4j 2.17.1
- If you’re on the 2.12.x branch for Java 7, upgrade to Log4j 2.12.4
- If you’re on the 2.3.x branch for Java 6, upgrade to Log4j 2.3.2
Log4j issue Strom
The disclosure of this vulnerability, has followed an increasingly worrying trend in irresponsible disclosures in Log4j, where security researchers have leaked details of the vulnerabilities they have disclosed before maintainers have had time to properly fix the issue and publish new releases.
This problematic phenomenon started with the original Log4j RCE wherein researchers leaked details and even a PoC of the vulnerability on Twitter and GitHub, hours before the official disclosure. 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.
Open source security is increasingly important to the world at large and responsible disclosure practice is a cornerstone of our community’s ongoing security. We hope that any future disclosures in Log4j or other open source packages can be more safely handled going forward.