Yesterday, Apache released Log4j version 2.17.1, which squashes a newly discovered code execution bug, tracked as CVE-2021-44832. Our Log4j vulnerability resource center has since been updated to reflect ongoing download trends and statistics for 2.17.1.
But the quasi-alarming code execution bug isn't as trivial to exploit as the original critical Log4Shell vulnerability (CVE-2021-44228) that set the internet on fire.
Before we dive further into the vulnerability details or if you need to worry about it, the possibility of an "RCE" flaw existing in Log4j 2.17.0 was initially brought up on Twitter by a researcher yesterday before any form of a formal disclosure took place. And this led to a storm of researchers from the InfoSec community flooding in to question and validate the claim.
Fortunately, it was later clarified by the researcher that the bug is an arbitrary, rather than, remote code execution, exploitable under very specific circumstances — although both Apache's advisory and the CVE entry classify the flaw as an "RCE."
Screen capture of the initial Twitter post and reply.
This did not sit well with everyone in the community [1] who had to dedicate significant time and effort towards investigating if the latest stable version prior to yesterday (Log4j 2.17.0), contained yet another serious vulnerability. Moreover, this came up during an unusually taxing holiday month for InfoSec professionals already underwater with the Log4j debacle.
Dissecting the vulnerability
Assigned a 'moderate' severity and a 6.6 CVSS score, CVE-2021-44832 concerns non-default scenarios of Log4j versions from 2.0-beta7 up to and including 2.17.0 (but excluding backported releases 2.3.2 and 2.12.4). It also requires an attacker to have "write" permissions to the logging configuration file to intentionally make these versions "vulnerable."
A successful attack depends on an attacker being able to modify the logging configuration file and "construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code," as the CVE advisory explains.
Apache has fixed the issue in versions 2.17.1 (Java 8), 2.12.4 (Java 7), and 2.3.3 (Java 6) by limiting JNDI data source names to the Java protocol, and introducing additional checks.
Fix that went into one of the classes in 2.17.1
In the fixed versions, the JDBC Appender has been modified to use JndiManager and requires that the log4j2.enableJndiJdbc system property is set to "true" for JNDI to be enabled. Further, the 'log4j2.enableJndi' property that was previously used to enable the JNDI functionality has been split into 3 properties (log4j2.enableJndiLookup, log4j2.enableJndiJms, and log4j2.enableJndiContextSelector). This allows sysadmins more flexibility, specificity with the individual JNDI features that need to be enabled if desired.
Note that JNDI functionality was itself hardened even in prior versions 2.17.0, 2.12.3, 2.12.3, 2.3.1, with only the JAVA protocol permitted for use with JNDI, and support for LDAP completely removed.
Cause for concern?
Despite the initial buzz generated around CVE-2021-44832 yesterday, many questioned if it merits being treated as a security vulnerability. Given a prerequisite for exploitation is an ability for the attacker to modify configuration files, it's likely in a different class. After all, if you have the ability to modify system configuration files, you would already possess access to other sensitive system areas. This would come from either some (unrelated) vulnerability exploit or another attack vector used for infiltration.
And the Sonatype security research team largely agrees. My friend and Sonatype security researcher, Ankita Lamba, drew parallels between this newly disclosed CVE, and another medium-severity flaw that lurked in the 'logback' logging framework. The 'logback' flaw, tracked as CVE-2021-42550 also required that an attacker possess sufficient "privileges to edit configurations files" for successful exploitation.
Security expert Kevin Beaumont acknowledged that the new Log4j CVE "only applies if an attacker can already modify the Log4j config file. If an attacker can modify your Log4j config file, they already own your webapp or host."
As tweeted by CERT vulnerability analyst Will Dormann, "I can achieve arbitrary code execution if I modify an application's openssl.cnf file to point to one of my libraries. Can I get a CVE for that too?"
Also in response to the CVE, a hacker who goes by "Tinker" taunted, "if a user has root/admin permissions and has network access to the system… they can access, alter, or destroy all data on the system."
Therefore, while the advice to upgrade to the latest Log4j version 2.17.1 and its backported counterparts is sound, the risk posed by CVE-2021-44832 isn't likely a reason to lose sleep over the holidays.
Need for coordinated disclosure
Another aspect of concern here is the haphazard nature of the disclosure. The series of events that preceded the CVE disclosure left many confused.
Lamba who, along with her colleagues, has spent her holiday week relentlessly analyzing Log4j bugs including CVE-2021-44832 speaks to the importance of responsible disclosure:
"One of the biggest takeaways from the events surrounding Log4j is that it is humanly impossible for maintainers of open source projects to cover each and every attack vector while fixing known vulnerabilities."
"This is why research and reporting of vulnerabilities done by the community is a boon to open source. But It can quickly become a bane if not done responsibly."
"Irresponsible disclosures stand to undermine the work of open source projects, as well as their maintainers and this issue will only grow bigger if not addressed."
As I said yesterday when first reporting the news on this CVE, disclosing security vulnerabilities prematurely can lure threat actors to conduct malicious scanning and exploitation activities. This is especially true when the issues are severe, as evidenced by the Log4Shell PoC exploit leak of December 9, 2021.
Lamba's advice comes at a time when a fintech firm was hit by a $5 million ransom demand, following a successful Log4Shell attack after the PoC exploit leaked.
Another important detail is that, unlike with all 4 Log4j CVEs reported so far, Apache's official advisory did not credit anyone for discovering CVE-2021-44832. This raises questions as to whether a coordinated disclosure protocol was adequately followed up until the last minute.
Screen capture of the credit line in the Log4j CVE.
Sonatype security research team has been closely monitoring developments on the continuously evolving Log4j situation and prioritizing these vulnerability disclosures. Within minutes of the researcher's tweet alleging the possibility of an RCE in version 2.17.0, our security researchers began investigating the claim and Fast-Tracked the vulnerability data with the available information to keep our customers safe, while full disclosure was pending.
After Apache's formal disclosure of the vulnerability, Deep Dive vulnerability research was prioritized.
Sonatype's advice for Log4j
No changes from what we've already advocated: Users should upgrade according to their version of Java.
-
Java 8 or later: v.2.17.1, available on Maven Central
-
Java 7: v.2.12.4
-
Java 6: v.2.3.2
-
Older releases: confirm that if the JDBC Appender is being used it is not configured to use any protocol other than Java.
Sonatype customers using Sonatype Platform products, such as Sonatype Lifecycle, need not worry as our security research and vulnerability data continues to protect their software development pipelines.
Finally, even if you aren't using any of Sonatype's products, Sonatype offers a vulnerability scanner you can download or use online. The report will detail usage of all vulnerable versions of Log4j in your repositories.
Headline image credit: Kit Ishimatsu
