News this week of the critical Apache vulnerability now known as "Text4Shell" raised great concern among some security pros that another Log4Shell event was at hand, but it turned out those fears were overblown.
In blog posts by Rapid7 and Checkmarx, researchers made clear that while CVE-2022-42889 should still be considered severe, it's not on the same level as Log4Shell. While that Apache vulnerability was exploitable in nearly ever application, this flaw can only be exploited by using Apache Commons Text in a specific way to expose the attack surface.
"Despite the many resemblances to [Log4Shell]...we must point out that the vulnerable package and functions is not as widely used in the wild," write Checkmarx researchers Yaniv Nizry and Miguel Correira. "Another major difference is in implementation. While the most fundamental use-cases of Log4j were vulnerable in Log4Shell, this vulnerability requires an implementation pattern that may not affect all of its users."
Some headlines even proclaimed that this was “like Log4Shell all over again.” To be fair, much of the chatter on Twitter was mixed, with enough people offering context versus those raising alarm bells.
Casey Ellis, founder and CTO at Bugcrowd, said there’s a phrase he uses every so often that’s a play on a fairly severe type of vulnerability: Remote Press Execution: when the press and social media respond to a vulnerability in a way that’s completely unrelated to the impact of the vulnerability itself.
“Referring to the Apache vulnerability as “4Shell” can be rationalized through the few similarities it has in that it’s a library, open-sourced, and it’s an input interpretation issue causing remote code recall,” Ellis said. “However, given what most folks remember about Log4Shell is the extreme disruption and difficulty it caused, I think it’s fair to say that it’s use here was premature.”
So given that the press will run with a story like this, how can security teams hold down the hysteria and sort out what’s really happening in each specific case?
“Experienced cybersecurity teams won’t panic or alter their processes because of a nickname,” said Craig Burland, chief information security officer at Inversion6. “They’ll evaluate the vulnerability on its technical merits and react accordingly. Good cybersecurity leaders will help people look beyond the name and hopefully take any interest as an opportunity to educate people about cyber risk.”
Burland added that it’s futile to try and legislate the nicknames of vulnerabilities. Use of “4Shell” may trend for a while, gathering more clicks and reposts, but it’s unlikely to stick around like “gate” spanning generations and covering everything from politics to sports (e.g. Watergate to Deflategate), said Burland. “On the plus side, if ubiquitous use of the “4Shell” suffix garners space in high-profile publications such as Forbes or the Wall Street Journal prompting more questions from business leaders then it will have served as a great user awareness tool,” Burland said.
Geoffrey Fisher, senior director, integration strategy at Tanium, said vulnerability names are simply just that: names and branding. Fisher said with any vulnerability an organization needs to understand a few aspects, its severity, its exploitability, and its velocity (e.g. spread in an organization) so they can adequately prioritize remediation.
“Every organization should take vulnerabilities with a grain of salt until they understand how it affects their environment,” Fisher said. “People use naming to create buzz and gain individual recognition. That needs to be kept in mind. This is yet another circumstance where marketing and branding has gotten ahead of reality. When that happens in any organization, frequently that's a recipe for a bad result. Most serious researchers hate this kind of behavior as it dilutes the seriousness of future warnings, especially when the house is actually on fire."
A newly patched version (1.10.0) of the software remediates the danger, and Erick Galinkin of Rapid7 advised companies to be on the lookout for follow-on advisories from vendors they rely on who may also use vulnerable implementations of the library, as they will also likely put out patches as well.
Of course, a flaw doesn't have to rise to the level of Log4Shell - a highly-exploitable vulnerability that the DHS Cyber Safety Review Board said "remains deeply embedded in systems" to this day despite a massive global response by the public and private sectors - to be worth your attention.
Phil Neray, vice president of cyber defense strategy at CardinalOps, said no matter what words are used to name this vulnerability, it's a serious one with a CVSS score of 9.8 because it lets a threat actor open a reverse shell connection with the vulnerable application simply via a specially crafted payload. Neray said this opens the door for follow-on attacks impacting confidentiality, integrity, and availability.
“According to WordPress security company Wordfence, threat actors are already attempting to exploit the newly disclosed flaw,” Neray said. “While it's true that, unlike with Log4Shell, not all users of this library will be affected, that doesn't lower the priority of understanding which of your custom and third-party applications are using the vulnerable versions and upgrading them to the fixed version as soon as possible. In the meantime, make sure you have detection rules as a compensating control in your SIEM/XDR to detect exploitation attempts.”
