Apache Commons Text RCE: Resemblance to Log4Shell but exposure risk is ‘much lower’

Log4Shell-like bug is serious but less dangerous than notorious Log4j vulnerability

A critical flaw patched in the Apache Commons Text library has sparked comparisons with the ‘Log4Shell’ bug that surfaced in the near-ubiquitous open source component Log4j last year.

However, the researcher who found and reported the Commons Text flaw in March has downplayed its comparative impact, while acknowledging a resemblance to the ‘Log4Shell’ vulnerability that is widely recognized as one of the most severe flaws of all time.

Lookup link

“The vulnerability is indeed very similar,” GitHub Security Lab principal researcher Alvaro Muñoz told The Daily Swig.

“The Apache Commons Text code appears to be based on the Log4j code, as both of them enable interpolation of multiple Lookup sources. Log4j enabled JNDI lookups [while] Apache Commons Text and Apache Commons Configuration allows script lookups – both could lead to RCE. The impact is, therefore, very high.

“However, it is worth keeping in mind that an issue's severity is calculated based on both the impact and the likelihood, and for the Apache Commons Text, the likelihood of untrusted data flowing to ACT's sink is much lower.”

Apache Commons Text performs text operations such as escaping, calculating string differences, and substituting placeholders in text with values looked up through interpolators. Fellow open source library Log4j is a Java-based logging utility.

Tracked as CVE-2022-42889, the Commons Text bug emerged on October 13 with an Apache Software Foundation (ASF) security advisory.

The vulnerability centers on an insecure implementation of the library’s variable interpolation functionality, namely that certain default lookup strings could potentially accept untrusted input from remote attackers, such as DNS requests, URLs, or inline scripts.

‘Clearly documented’

A technical analysis published yesterday by Rapid7 also attempted to tamp down hype over the bug, whose CVSS score of 9.8 is nevertheless close to Log4Shell’s perfect 10 on the severity front.

The vulnerable “StringSubstitutor interpolator is considerably less widely used than the vulnerable string substitution in Log4j and the nature of such an interpolator means that getting crafted input to the vulnerable object is less likely than merely interacting with such a crafted string as in Log4Shell,” said Rapid7.

Arnout Engelen, security response program manager at the ASF, echoed these sentiments, telling The Daily Swig: “In Log4Shell, string interpolation was possible from the log message body, which commonly contains untrusted input. In the Apache Common Text issue, the relevant method is explicitly intended and clearly documented to perform string interpolation, so it is much less likely that applications would inadvertently pass in untrusted input without proper validation.”

Remediation

The flaw affects Apache Commons Text versions 1.5 through 1.9, and all JDK versions, and has been patched in version 1.10.

Engelen said: “When using the string substitution feature, some of the available interpolators can trigger network access or code execution. This is intended, but it also means an application that includes user input in the string passed to the substitution without properly sanitizing it would allow an attacker to trigger those interpolators.

“For that reason the Apache Commons Text team have decided to update the configuration to be more ‘secure by default’, so that the impact of a failure to validate inputs is mitigated and will not give an attacker access to these interpolators.

“However, it is still recommended that users treat untrusted input with care. We’re not currently aware of any applications that pass untrusted input to the substitutor and thus would have been impacted by this problem prior to Apache Commons Text 1.10.0.”

Rapid7 recommends that developers and maintainers watch out for follow-on vendor advisories, install “patches as they become available, and prioritize anywhere the vendor indicates that their implementation may be remotely exploitable”.