Earlier this month, a security vulnerability discovered in the popular Java-based logging package “Log4j” became a massive problem for countless companies and tech products. Minecraft, Steam, Apple iCloud, and other applications and services had to rush updates with a patched version, but Log4j’s problems haven’t been completely fixed yet. Now yet another update is rolling out, which aims to fix another potential security issue.
The Apache Software Foundation released version 2.17.1 of Log4j on Monday (via Bleeping Computer), which primarily addresses a security flaw labeled as CVE-2021-44832. The vulnerability could potentially allow remote code execution (RCE) using the JDBC Appender if the attacker can control the Log4j logging configuration file. The issue has been given a “Moderate” severity rating, lower than the vulnerability that started it all — CVE-2021-44228, which is rated “Critical”. Checkmarx security researcher Yaniv Nizry claimed credit for discovering the vulnerability and reporting it to the Apache Software Foundation.
Apache wrote in the vulnerability description, “Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.”
The original Log4j exploit, which is also known as “Log4Shell,” allowed malicious code to be executed on many servers or applications that used Log4j for data logging. Cloudflare CEO Matthew Prince said that the exploit was being used as early as December 1, over a week before it was publicly identified, and according to The Washington Post, Google tasked over 500 engineers with pouring through the company’s code to ensure nothing was vulnerable. This vulnerability is nowhere near as severe, as an attacker still needs to be able to modify a configuration file belonging to Log4j. If they can do that, you likely have bigger problems on your hands anyway.
This latest release is expected to be the final permanent fix for the original exploit, which many companies already fixed on their own. However, we’ve also seen several other updates since the initial one to close loopholes that were later discovered. With any luck, this should finally be the end of the Log4Shell saga.