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/
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.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demo
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/
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/
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demo
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/
Table of contents
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
The Secure-by-Design movement is the future of secure software development. Learn about the key elements companies need to keep in mind when they think about a Secure-by-Design initiative.
DigitalOcean Decreases Security Debt with Secure Code Warrior
DigitalOcean's use of Secure Code Warrior training has significantly reduced security debt, allowing teams to focus more on innovation and productivity. The improved security has strengthened their product quality and competitive edge. Looking ahead, the SCW Trust Score will help them further enhance security practices and continue driving innovation.
Resources to get you started
Trust Score Reveals the Value of Secure-by-Design Upskilling Initiatives
Our research has shown that secure code training works. Trust Score, using an algorithm drawing on more than 20 million learning data points from work by more than 250,000 learners at over 600 organizations, reveals its effectiveness in driving down vulnerabilities and how to make the initiative even more effective.
.png)
Reactive Versus Preventive Security: Prevention Is a Better Cure
The idea of bringing preventive security to legacy code and systems at the same time as newer applications can seem daunting, but a Secure-by-Design approach, enforced by upskilling developers, can apply security best practices to those systems. It’s the best chance many organizations have of improving their security postures.
The Benefits of Benchmarking Security Skills for Developers
The growing focus on secure code and Secure-by-Design principles requires developers to be trained in cybersecurity from the start of the SDLC, with tools like Secure Code Warrior’s Trust Score helping measure and improve their progress.
Driving Meaningful Success for Enterprise Secure-by-Design Initiatives
Our latest research paper, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise is the result of deep analysis of real Secure-by-Design initiatives at the enterprise level, and deriving best practice approaches based on data-driven findings.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
