New vulnerabilities in Spring libraries: how to know if you are at risk and what to do
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
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? Book a demo or explore our free secure coding guidelines on secure code coach.
Sources
- https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
- https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/
Share Article
Related Articles We Recommend
.png)
Related Articles We Recommend
Dive into onto our latest secure coding insights on the blog.
Our extensive resource library aims to empower the human approach to secure coding upskilling.
Get the latest research on developer-driven security
Our extensive resource library is full of helpful resources from whitepapers to webinars to get you started with developer-driven secure coding. Explore it now.
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). 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? Book a demo or explore our free secure coding guidelines on secure code coach.
Sources
- https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
- https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/
