Getty Images
Hype and hype was in full force this week as the security world reacted to reports of yet another Log4Shell. The vulnerability became known in December and is probably one of the most serious Internet threats in years. Dubbed Spring4Shell, the new code execution bug in Spring’s widely used Java framework quickly set the security world on fire as researchers struggled to assess its severity.
One of the first posts to report on the bug was tech news site Cyber Kendra, which warned of the serious damage the bug could do “tons of apps” and “ruin the internet.” Almost immediately, security firms, many pumping snake oil, scrambled to warn of the imminent danger we would all face. And all of this before a vulnerability tracking designation or advisory was even available from Spring maintainers.
All aboard
The hype train began Wednesday after a researcher published a proof-of-concept exploit that could remotely install a web-based remote control backdoor known as a web shell on a vulnerable system. People were understandably concerned because the vulnerability was so easy to exploit and resided in a framework that powers a large number of websites and apps.
The vulnerability exists in two Spring products: Spring MVC and Spring WebFlux, which allow developers to write and test apps. The bug results from changes introduced in JDK9 that resurrected a decades-old vulnerability tracked as CVE-2010-1622. Given the plethora of systems combining the Spring framework and JDK9 or higher, it was no wonder people were concerned, especially since exploit code was already in the wild (the first leaker quickly shut down the PoC, but there was it too late).
Finally, on Thursday, the bug was named CVE-2022-22965. Security defenders were also given a much more nuanced description of the threat they posed. The leaked code, Spring maintainers said, ran only when a Spring-developed app ran on Apache Tomcat, and then only when the app was deployed as a file type known as a WAR, short for web archive.
“If the application is deployed as a Spring Boot executable JAR file, i.e. by default, it is not vulnerable to the exploit,” the Spring maintainers wrote. “However, the nature of the vulnerability is more general, and there may be other ways to exploit it.”
advertisement
While the post left open the possibility that the PoC exploit could be enhanced to work against other configurations, no one has spotted a variant that does, at least until now.
“It’s one thing that developers should fix when using an affected version,” said Will Dormann, vulnerability analyst at CERT, in a private message. “But we’re still in the same boat as we don’t know of a single application that can be exploited.”
On Twitter, Dormann Cyber took Kendra to task.
“How Cyber Kendra made it worse for everyone,” he wrote. “1) Sensational blog post suggesting this will ruin the internet (red flag!) 2) Linking to a Git commit about deserialization that has absolutely nothing to do with the issue pointed out by the original party.”
Ways Cyber Kendra has made this worse for everyone:
1) Sensational blog post suggesting this will ruin the internet (red flag!).
2) Linking to a git commit about deserialization that has absolutely nothing to do with the problem pointed out by the original party. pic.twitter.com/91MAfL7K4r— Will Dormann (@wdormann) March 31, 2022
A Cyber Kendra representative did not respond to an email requesting comment. In fairness, the line about destroying the internet was later crossed out.
SpringShell, not Spring4Shell
Unfortunately, while the consensus is that the vulnerability is nowhere near the threat posed by Log4Shell, at least for now, the Spring4Shell name has largely stuck. That will likely mislead some as to its severity. In the future, Ars will refer to it by its more apt name, SpringShell.
Several researchers say they have discovered scans in the wild that use the leaked CVE-2022-22965 PoC or a very similar exploit. It’s not uncommon for researchers to benevolently test servers to understand how prevalent a new vulnerability is. Slightly more worrisome is a report on Friday in which Netlab 360 researchers said that a variant of Mirai — malware that can target thousands of IoT devices and generate crippling denial-of-service attacks — “won the race to be the first botnet.” has that has taken on this vulnerability.”
To confuse matters further, a separate code execution vulnerability emerged last week affecting the Spring Cloud feature that allows developers to easily decouple the business logic in an app from a specific runtime. The bug tracked as CVE-2022-22963 resides in Spring Expression Language, commonly known as SpEL.
Both vulnerabilities are potentially serious and should not be ignored. That means upgrading the Spring Framework to 5.3.18 or 5.2.20 and also upgrading to Tomcat 10.0.20, 9.0.62 or 8.5.78 as a precaution. Those using the Spring Cloud feature should upgrade to either 3.1.7 or 3.2.3.
For people who aren’t sure if their apps are vulnerable to CVE-2022-22965, researchers at security firm Randori have a simple, non-malicious script it can do just that.
So by all means test and patch like there’s no tomorrow, but don’t believe the hype.