A remote code execution vulnerability in Spring Framework has sparked fears that it could have a widespread impact across enterprise environments. Spring is one of the most popular open-source frameworks for developing Java applications.
The flaw, which has since been dubbed SpringShell or Spring4Shell, came to light when a Chinese developer released a proof-of-concept (PoC) exploit on GitHub and then removed it, prompting widespread speculation about the unpatched flaw, its causes and potential impact. There was also some early confusion between this vulnerability and a different one patched Tuesday in Spring Cloud, a microservices library that’s different from the core Spring Framework. That vulnerability is tracked as CVE-2022-22963.
The Spring developers have now confirmed the existence of this new vulnerability in Spring Framework itself and released versions 5.3.18 and 5.2.20 to address it. Spring Boot, a related tool for packaging pre-built stand-alone Spring-based applications, also received updates 2.6.6 and 2.5.12.
What we know about Spring4Shell
The vulnerability is tracked as CVE-2022-22965 and is rated critical. The Spring developers confirmed that its impact is remote code execution (RCE), which is the most severe impact a vulnerability could have.
The vulnerability impacts Spring MVC and Spring WebFlux applications that are packaged as WAR archives, are deployed to Apache Tomcat servers and run on JDK 9 and higher. Since WAR is a popular format for packaging Java applications, Tomcat is one of the most popular Java web servers and JDK 9 was released in 2017, the number of impacted applications could be significant.
The developers also warn that the nature of the vulnerability is more general and that there might be other ways to exploit it, including on Spring Boot with embedded Tomcat. They also warn that the workarounds suggested by other security experts online, which involve setting disallowedFields on WebDataBinder through an @ControllerAdvice, might leave some loopholes.
“To apply the workaround in a more fail-safe way, applications could extend RequestMappingHandlerAdapter to update the WebDataBinder at the end after all other initialization,” the developers said. “In order to do that, a Spring Boot application can declare a WebMvcRegistrations bean (Spring MVC) or a WebFluxRegistrations bean (Spring WebFlux).”
Examples of implementing the workaround are provided in the provisional security advisory.
Confusion with CVE-2022-22963
Early reports about the existence of a remote code execution vulnerability led to some people confusing it with CVE-2022-22963, a flaw in Spring Cloud Function that was patched Tuesday and whose impact and severity researchers think was misrepresented.
VMware describes it as a medium severity resource access issue, but other researchers pointed out that it can actually lead to remote code execution and is therefore more dangerous and should be rated as high severity. The vulnerability is related to a feature called Spring Expression Language (SpEL) and was patched in Spring Cloud Function 3.1.7 and 3.2.3.
Spring Cloud is a framework that implements many of the features needed to develop cloud applications for distributed systems. It provides sub-components for integration with specific public clouds such as Azure, AWS and Alibaba as well as implementation of more general concepts such as configuration management, service discovery, circuit breakers, intelligent routing, distributed sessions, cluster state and more. One of those components is Spring Cloud Function, which aims to provide a uniform programming model across serverless providers and allows developers to implement business logic via functions.
Confusion about deserialization and impact
News about the RCE vulnerability in Spring started circulating on Twitter on Wednesday and received the name SpringShell, a clear reference to Log4Shell, a critical vulnerability disclosed in December in the popular Log4j Java logging library that impacted millions of Java-based applications.
Some of the early reports drew parallels to Log4Shell because Spring is a very popular development framework for both desktop and Web-based Java applications. However, those reports also contained somewhat conflicting information, referencing a recent Spring code commit to deprecate SerializationUtils#deserialize, a feature long known to be unsafe to use with objects from untrusted sources. The Spring developers had to post comments on the code tracker to clarify that the code commit was not related to any new vulnerabilities.
Other early reports also mentioned deserialization, introducing doubt about whether this is actually a vulnerability in Spring or the incorrect use by the PoC author of a feature known to be unsafe. Furthermore, it wasn’t clear how steep the exploitation requirements were and how many real-world applications met them.
Even now it’s not clear how many applications are vulnerable. The Spring advisory doesn’t contain a lot of details about the source of this vulnerability, but several security companies who analyzed the original PoC provided and were able to create working exploits based on it provided more information in their advisories.
Researchers from security firm Praetorian described it as a bypass for a much older vulnerability tracked as CVE-2010-1622 and said exploitation requires an endpoint with DataBinder enabled, depending heavily on the servlet container for the application.
Researchers from Sonatype noted in their analysis that the PoC leveraged “a previously unknown method to achieve remote code execution (RCE)” and confirmed the link to the CVE-2010-1622 issue, saying the underlying problem behind that vulnerability became exploitable again when used with JDK9.
Researchers from application security firm Contrast Security added more context.
“In the process of building an object graph to give to the developer, Spring takes special care not to let attackers control any parts of the Class, ProtectionDomain, and ClassLoader of the instance being created,” they said. “Unfortunately, changes to the Class object in Java 9 meant the checks Spring performed were no longer enough.”
In particular, the introduction of Class#getModule() which is not covered by the previous checks, essentially opens a new path to exploiting the issue.
The attack flow works as follows: The attackers change the target of the ClassLoader’s logging facility to create a new, malicious JSP file. They then use a few tricks to write malicious code into the JSP file, creating a backdoor and then make requests to the new backdoor to invoke system commands.
“This is bad, but doesn’t seem as bad as Log4Shell,” researchers from DevOps specialist firm JFrog said on Twitter. “From our research, not all Spring apps are vulnerable (only apps that bind request parameters to a POJO) and the most popular JDK version (8) is not affected (only 9+ are affected).”
The JFrog researchers developed and released a free tool that can help users scan their Java applications to determine whether they might be vulnerable. The condition of Spring endpoints binding request parameters to a non-primitive (Java Bean) type might be rare, which could make most applications non-exploitable in practice, the tool’s description says.
“The new vulnerability does seem to allow unauthenticated RCE but at the same time, has mitigations and is not currently at the level of impact of Log4j,” Brian Fox, CTO of Sonatype, tells CSO. “We’re continuing to look into this to determine how it will shake out. However, we can appreciate the recent Log4shell memory is rightfully causing anxiety in the industry, as Spring is one of the most popular software frameworks out there. Regardless, this should act as another reason for every organization to take stock of how they are managing their third-party components.”
Copyright © 2022 IDG Communications, Inc.
