Spring4Shell—Similar Name, Minimal Impact

Researchers recently “disclosed” (information was actually leaked on Twitter ahead of the CVE) a new remote code execution (RCE) vulnerability in Spring Core. This popular web application development framework is used by millions of developers to build modern enterprise applications in Java. And though additional research seems to indicate panic is probably overblown, the potential impact has developers and security teams worried – enough so to christen the vulnerability, Spring4Shell.

What is the issue?

For starters, this should not be confused with CVE-2022-22963 or CVE-2022-27772 as those issues are separate from Spring4Shell.

CVE-2022-22965, which was published yesterday, describes the exploit as follows:

“Spring MVC or Spring WebFlux application[s] running on JDK 9+ may be vulnerable to remote code execution (RCE) via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit.”

Additionally, the CVE provides the following requirements:

• JDK 9 or higher
• Apache Tomcat as the Servlet container
• Packaged as WAR
• spring-webmvc or spring-webflux dependency

What is the impact?

Given the specifics of the exploit, there seems to be a consensus forming that Spring4Shell’s impact may not be as severe as initially reported. “This does not instinctively seem like it’s going to be a cataclysmic event such as Log4Shell” wrote Chris Partridge, Security Engineer at AWS, in his extremely thorough write-up on Github.

That said, since the publication of this CVE, several cases have been discovered in the wild, most notably in the “Handling Form Submission” tutorial from Spring -thanks to Will Dormann, Vulnerability Analyst at the CERT/CC, for confirming on Twitter! And because this exploit deals with RCE, it’s going to be important for people to determine their risk exposure.

Further limiting the impact of Spring4Shell, attackers must know the address, including the application’s endpoint, to exploit the vulnerability – which also means applications not exposed to the internet are safe. For those who remember, this was not the case with Log4Shell where attackers could use a compromised machine to orchestrate attacks on the internal network, significantly expanding the attack surface.

“Log4Shell was much worse, because the exploit could hit systems that were not directly connected to the Internet,” he says. “In this case, you are going to be needed to be hitting the machine.”

How to test?

For those interested in testing the exploit themselves, the following non-malicious requests provided by Randori Security’s Attack Team seems to be the simplest, most straightforward test for determining whether a service/system is vulnerable.

$ curl host:port/path?class.module.classLoader.URLs%5B0%5D=0

How to mitigate?

According to updates provided on the Spring Blog, the vulnerability is now fixed in Spring Framework versions 5.3.18 and 5.2.20. It’s worth reviewing the above post for additional details, particularly if you’re unable to upgrade.

Conclusion

While Spring4Shell is absolutely something you should investigate and patch, the similarities to Log4Shell (more-or-less) end there … Actually, as our CTO, Mike Larkin, bemoaned in his blog on Log4j, this is a good time to remind everyone that panic and misinformation only make understanding, triaging, and remediating the problem harder.

Regardless, the best defense for this type of vulnerability is to patch it as soon as possible! That said, having a clear understanding of the packages being used in your environment is a must in today’s world – consider using a tool like Deepfactor to help your developers identify and prioritize systems appropriately.