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 gravest 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 scrambled to assess its severity.

One of the first posts to report on the flaw was tech news site Cyber Kendra, which warned of severe damage the flaw might cause to “tonnes of applications” and “can ruin the Internet.” Almost immediately, security companies, many of them pushing snake oil, were falling all over themselves to warn of the imminent danger we would all face. And all of that before a vulnerability tracking designation or advisory from Spring maintainers was even available.

All aboard

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 was in a framework that powers a massive number of websites and apps.

The vulnerability resides 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 resurrected a decade-old vulnerability tracked as CVE-2010-1622. Given the abundance of systems that combine the Spring framework and JDK9 or later, no wonder people were concerned, particularly since exploit code was already in the wild (the initial leaker quickly took down the PoC, but by then it was too late.)

On Thursday, the flaw finally received the designation CVE-2022-22965. Security defenders also got a much more nuanced description of the threat it posed. The leaked code, Spring maintainers said, ran only when a Spring-developed app ran on top of Apache Tomcat and then only when the app is deployed as a file type known as a WAR, short for web archive.

“If the application is deployed as a Spring Boot executable jar, i.e. the 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.”

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

“It’s a thing that developers should fix, if they’re using an affected version,” Will Dormann, a vulnerability analyst at CERT, said in a private message. “But we’re still in the boat of not knowing of a single application out there that is exploitable.”

On Twitter, Dormann took Cyber Kendra to task.

“Ways that Cyber Kendra made this worse for everyone,” he wrote. “1) Sensational blog post indicating that 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 issue demonstrated by the original party.”

A Cyber Kendra representative didn’t respond to an email seeking comment. In fairness, the line about ruining the internet was later struck through.

SpringShell, not Spring4Shell

Sadly, even though there’s consensus that, at least for now, the vulnerability doesn’t pose anything near the threat of Log4Shell, the Spring4Shell name has largely stuck. That’s will likely mislead some about its severity. Going forward, Ars will refer to it by its more appropriate name, SpringShell.

Several researchers say they have detected scans in the wild that use the leaked CVE-2022-22965 PoC or an exploit very much like it. It’s not unusual for researchers to benignly test servers to understand how prevalent a new vulnerability is. Slightly more concerning is a report on Friday in which researchers from Netlab 360 said a variant of Mirai—malware that can wrangle thousands of IoT devices and produce crippling denial-of-service attacks—“has won the race as the first botnet that adopted this vulnerability.”

To make matters more confusing, a separate code-execution vulnerability surfaced last week that affects Spring Cloud Function, which allows developers to easily decouple the business logic in an app from a specific runtime. The flaw, tracked as CVE-2022-22963, resides in the Spring Expression Language, typically known as SpEL.

Both vulnerabilities are potentially serious and should by no means be ignored. That means updating the Spring Framework to 5.3.18 or 5.2.20, and out of an abundance of caution also upgrading to Tomcat 10.0.20, 9.0.62, or 8.5.78. Those using the Spring Cloud Function should update 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 released a simple, non-malicious script that can do just that.

So by all means, test and patch like there’s no tomorrow, but don’t believe the hype.