Experts downplay reach of Apache bug ‘Text4Shell’
Cybersecurity researchers are tamping down concerns around a recently discovered vulnerability affecting the popular Apache Commons Text library.
In a security bulletin on October 13, the Apache Commons Text team recommended users update to v1.10.0, which disables the issue — named CVE 2022-42889 — by default.
The bug initially caused concern, with some comparing it to more ubiquitous vulnerabilities like Log4j or smaller-scale ones like Spring4Shell. But several cybersecurity experts contacted by The Record disagreed with the assessment, noting that the bug — known informally as “Text4Shell” — was far more limited than both of those vulnerabilities.
Tenable senior research engineer Claire Tills said that while the vulnerability has a 9.8 CVSS score (10 being the highest level of severity), it appears to require specific application development practices and configurations that likely aren’t common.
Contrast Security CISO David Lindner echoed that assessment, noting that it is not “not nearly as widespread or exploitable” as Log4j or Spring4Shell.
“The class/method involved in this vulnerability is rarely used and a quick GitHub search shows very few open source programs using the vulnerable method, and most that are, are not parsing user controlled input,” he said.
“From what we’ve seen so far, this CVE seems more like a developer adding a backdoor, more than anything. I’m not as concerned that this will amount to much, as it’s not like Log4j where an application is gathering user controlled input and logging it, which could result in exploiting the log4shell vulnerability.”
Bugcrowd CTO Casey Ellis explained that while Apache itself is ubiquitous and often exposed to the public internet, exploiting the vulnerability appears to have a number of prerequisites, and for now they aren’t seeing widespread exploitation.
“That said, it’s a good time for organizations to ensure a solid understanding of where Apache, and especially Apache Commons Text, exists in their attack surface, plan for patching it, and prepare for the possibility of emergency patching or mitigation if exploitation takes off,” he said.
“At this point, I believe that exploitable versions in the wild are less common than first thought, but this isn’t necessarily cause to relax. The more important question for defenders to be asking is ‘do we know if we have a vulnerable version of this in our Apache software supply chains’ as well as ‘does the vulnerable library exist in COTS [commercial off-the-shelf] products or hardware that we don’t control ourselves.'”
Arnout Engelen, security response program manager at Apache, told The Record that Apache Commons Text is a low-level library for performing various text operations, such as escaping, calculating string differences, and substituting placeholders in the text with values looked up through interpolators.
“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,” Engelen explained.
“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.”
Engelen said they are not currently aware of any applications that would have been impacted by the problem. A proof of concept exploit is available, according to several researchers.
Sophos’ Christopher Budd agreed that the Common Text library isn’t as prevalent as Log4j and “likely requires code that is specific and targeted.”
“Most applications will not be passing unsanitized user provided values to the library’s vulnerable functions, reducing or negating the exploitation risks,” Budd said.
“Sophos X-Ops is not currently seeing the attacks exploiting CVE-2022-42889 in the wild, but will continue monitoring.”
Shachar Menashe, senior director of security research for JFrog, said it is still possible the issue will gain traction if researchers start finding other popular 3rd-party services that use this library.
But as of now, no such 3rd-party services have been found, Menashe noted. JFrog wrote an open source tool to detect Java binaries that are vulnerable to this issue.