Secure Code Warrior

New vulnerabilities in Spring libraries: how to know if you are at risk and what to do

Recently, Spring libraries, one of the most popular libraries in the Java community, disclosed 2 vulnerabilities related to Remote Code Execution (RCE). We’ve broken down the known details for “Spring4Shell” and “Spring Cloud Function” to help you understand if you're at risk and what to do if you are.

Recently, Spring libraries, one of the most popular libraries in the Java community, disclosed 2 vulnerabilities related to Remote Code Execution (RCE). To help make it easier for you to understand if you are at risk for either vulnerability and what actions to take, we’ve broken down the known details for “Spring4Shell” and “Spring Cloud Function.”

Vulnerability 1 - “Spring4Shell” (CVE-2022-22965)

On March 29th, 2022, the community discovered a series of tweets containing screenshots of a proof of concept of an exploit targeting Spring Core (SC) , which allows for Remote Code Execution for all versions of Spring Core, including the most recently released version, 5.3.17.

What applications are at risk?

Currently, only applications being hosted on Tomcat are confirmed to be at risk to this new exploit. While the exploitation has not been demonstrated as successful against the Embedded Tomcat Servlet Container, or any other non-Tomcat hosted applications, that does not rule out the possibility of the threat proving successful in the future to these frameworks. 

Spring released an official statement about the vulnerability, which clarifies that the following conditions need to be met to be vulnerable, according to the current understanding of the vulnerability:

  • JDK 9 or higher
  • Apache Tomcat as the Servlet container
  • Packaged as a traditional WAR (in contrast to a Spring Boot executable jar)
  • spring-webmvc or spring-webflux dependency
  • Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions

How does the “Spring4Shell” exploitation work?

The exploitation relies on using “Data Binding” (org.springframework.web.bind.WebDataBinder) in requests that make use of Plain Old Java Objects (POJO) in the method signature:

Where the Foo class is a POJO class, which could be defined as the following. Note that the actual class isn’t important, as long as it’s loaded by the Class Loader. 

When a request is handled by a method like this, the Class Loader is used to resolve the class. The Class Loader is responsible for loading classes at runtime, without having to preload all possible types into memory first. It figures out which .jar file to load when a new class is used. 

You can find the most up to date and in-depth information about this vulnerability directly from Spring on their blogpost, including potential fixes or workarounds.

Vulnerability 2 - Spring Cloud Function (CVE-2022-22963)

On March 27th 2022, Cyber Kendra disclosed details about a 0-day Remote Code Execution (RCE) vulnerability in Spring Cloud Functions for which no patch existed. The vulnerability was assigned the ID CVE-2022-22963: Spring Expression Resource Access Vulnerability.

What applications are at risk?

The vulnerability affected applications under these conditions:

  • JDK 9 or newer
  • Spring Cloud Functions version 3.1.6 (or lower), 3.2.2 (or lower), or any unsupported version 

How does the exploitation work?

Spring Cloud Function provides the capability for developers to configure how routing is handled through the property ​​spring.cloud.function.routing-expression, usually done through configuration, or code. This is a powerful capability that accepts the “Spring Expression Language” (SpEL). Through this 0-day vulnerability, we have learned that this property could be set through the HTTP headers of a request, which meant that an attacker could embed SpEL code directly in their HTTP request to a RoutingFunction endpoint, and thus execute arbitrary code. 

What steps should users take to mitigate risk?

Spring has released versions 3.1.7 and 3.2.3 to address this issue by not allowing this property to be set through HTTP headers, mitigating the vulnerability. After upgrading to either version, no additional steps are necessary.

Interested in learning more about how we help developers write more secure code? Visit our showcase and try out some of our interactive content.