Apache Commons Vulnerability: Patch but Don't Panic

Researchers who have analyzed the recently disclosed vulnerability in Apache Commons Text — referred to by some as Text4Shell — described it this week as serious but unlikely to be as disruptive as last year's Log4j bug.

The flaw (CVE-2022-42889) is present in versions 1.5 through 1.9 of Apache Commons Text and gives attackers a way to run malicious code remotely on vulnerable systems. The Apache Software Foundation (ASF) disclosed the flaw last week in a brief advisory and recommended that organizations upgrade to Apache Commons Text 1.10.0, a version that the ASF released on Sept. 24 or more than two weeks before bug disclosure.

CVE-2022-42889 stems from insecure defaults when Apache Commons Text performs a function called variable interpolation, which involves the process of looking up and evaluating code strings that contain placeholders. According to the ASF, the set of Lookup instances in versions 1.5 through 1.9 of Apache Commons Text included interpolators that could trigger arbitrary code execution or contact with remote servers. Since the vulnerability was disclosed, several researchers have released proof-of-concept code showing how it can be exploited and scanners for finding potential targets to attack.

Shachar Menashe, senior director of security research at JFrog, says Apache Commons Text (ACT) is an extremely common Java library focused on algorithms that work on strings. "ACT provides an API to perform variable interpolation — or substitution — allowing properties to be dynamically evaluated and expanded," Menashe says. "Some functions of this library were found to lead to remote code execution if attacker-controlled data is passed to these functions."

There are three potential substitution sources that could have a security impact if an attacker has control of the string being interpolated: script, dns, and url, he explains. Attackers could use the script source to execute arbitrary JavaScript code; they could use the dns source to proxy dns requests, and the url source as a server-side request forgery vector, Menashe says.

However, "the vulnerability can only be exploited in cases where some Java code exists that uses [Apache Commons Text] and passes attacker-controlled data to specific functions," he says. "We believe exploitation won't be as widespread as Log4Shell since these functions seem to be less likely to receive external user input." 

An attacker would have to research the target Java application and find an input that is passed to the vulnerable functions, which the attacker can control, Menashe says. At the same time, it's unwise to rule out that possibility.

"It's still possible this will blow up if researchers start finding other popular third-party services that use this library and pass external input to these vulnerable functions by default," Menashe notes. "But as of now, no such third-party services have been found."

ASF describes the Commons Text library as providing additions to the standard Java Development Kit's (JDK) text handling. Sonatype's Maven Central Java repository lists 2,588 projects that currently use the library. Among them are Apache Hadoop Common, Apache Velocity, Spark Project Core, and Apache Commons Configuration,

Widespread Exploitation Seems Unlikely

Erick Galinkin, principal researcher at Rapid7, says the fact that CVE-2022-42889 is a library vulnerability makes it hard to say for certain what its impact will be. A lot depends on how the vulnerable object is used in a particular application. "Overall, our assessment is that the vulnerability is potentially serious," he says. "It is certainly important to patch affected applications as those patches become available, but not worth panicking over."

The severity is really a function of how the vulnerable object — the Commons Text StringSubstitutor interpolator — is used. "If there's an application out there that is using the interpolator on arbitrary untrusted input, a user of that application is going to have a bad time," he says. 

But based on initial research, the vulnerable object isn't very common, and it is implausible for an unprivileged attacker to actually gain control of the relevant strings. "That said, there may still be some application using this in a way that is risky, and in that case, the potential for code execution is very high," Galinkin said.

He adds that the ability for an attacker to discover vulnerable targets depends on how an organization might have implemented the vulnerable component. "Many of the proofs-of-concept for the vulnerability, including ours, just involve passing a crafted string to the interpolator — so in that sense, it is extremely easy to exploit," he says. In many other implementations an attacker would need to already have some level of access, making it difficult to exploit.

Menashe notes that JFrog has written an open source tool to detect Java binaries that are vulnerable to this issue. The tool can help organizations determine whether the version of commons-text is vulnerable.

He adds: "The tool also locates the calls to the vulnerable functions in compiled [.jar files] and reports the findings as class name and method names in which each vulnerable call appears."