Explaining Spring4Shell: The Internet Security Disaster That Wasn’t

Hype and hyperbole were on full display this week as the security world reacted to reports of yet another Log4Shell. The vulnerability came to light in December and is arguably one of the biggest internet threats in years. Christened Spring4Shell – the new code execution bug in the widely used Spring Java framework – quickly set the security world on fire as researchers rushed to assess its severity.

One of the first to report on the flaw was the tech news site Cyber ​​Kendra, which warned of serious damage the flaw could cause to “tons of applications” and “ruin the internet”. Almost immediately, security companies, many of them selling snake oil, fell over themselves to warn of the impending danger we would all face. And all before there was even a hint of vulnerability tracking or advice from Spring administrators.

Everyone on board

The hype train started on 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 contained within a framework that powers a huge number of websites and apps.

The vulnerability is in two Spring products: Spring MVC and Spring WebFlux, which allow developers to write and test apps. The flaw results from changes introduced in JDK9 that revived a decade-old vulnerability, which was tracked as CVE-2010-1622. Given the plethora of systems combining the Spring framework and JDK9 or higher, it’s no wonder people were concerned, especially since exploit code was already out in the wild (the first leaker took out the PoC quickly, but by then it was too late .)

On Thursday, the error was finally designated CVE-2022-22965. Security defenders were also given a much more nuanced description of the threat it posed. The leaked code, Spring administrators said, only worked when a Spring-developed app ran on top of 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 implemented as a Spring Boot executable jar, ie the default, it is not vulnerable to abuse,” the Spring administrators wrote. “However, the nature of the vulnerability is more general and there may be other ways to exploit it.”

While the post left open the possibility that the PoC exploit could be improved to work against other configurations, no one has discovered a variation that does, at least for now.

“It’s something developers need to fix if they’re running an affected version,” Will Dormann, a vulnerability analyst at CERT, said in a private message. “But we’re still in the boat because we don’t know of any application that can be exploited.”

On Twitter, Dormann took up Cyber ​​Kendra.

“Ways Cyber ​​Kendra Made This Worse For Everyone,” He Said wrote† “1) Sensational blog post indicating this is going to ruin the internet (red flag!) 2) Linking to a git commit about deserialization that has absolutely nothing to do with the problem demonstrated by the original party.”

A Cyber ​​Kendra representative did not respond to an email asking for comment. Frankly, the line about ruining the internet was later crossed out.

spring shell, not Spring4Shell

Unfortunately, while there is consensus that, at least for now, the vulnerability is nothing close to the Log4Shell threat, the Spring4Shell name has largely stuck. That will probably mislead some as to its seriousness. In the future, Ars will refer to it with the more appropriate name SpringShell.

Several researchers say they have detected scans in the wild using the leaked CVE-2022-22965 PoC or an exploit very similar. It’s not uncommon for researchers to benignly test servers to understand how common a new vulnerability is. A little more troubling is a report from Friday in which Netlab 360 researchers said that a variant of Mirai — malware that can confuse thousands of IoT devices and produce crippling denial-of-service attacks — “has won the race if it first botnet to adopt this vulnerability.”

To make things more confusing, a separate code execution vulnerability surfaced last week affecting Spring Cloud Function, which allows developers to easily decouple the business logic in an app from a specific runtime. The error, tracked as CVE-2022-22963, is in the Spring Expression Language, commonly known as SpEL.

Both vulnerabilities are potentially serious and should not be ignored under any circumstances. That means updating 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 update to 3.1.7 or 3.2.3.

For people who aren’t sure whether their apps are vulnerable to CVE-2022-22965, researchers at security firm Randori have created a simple, non-malicious script that’s just possible.

So at least test and patch like there’s no tomorrow, but don’t believe the hype.