Spring4Shell Zero-Day Vulnerability: Information and Remediation for CVE-2022-22965
Updates
The Mend research team will update this blog and our Mend resources as we learn more about CVE-2022-22965.
April 13, 2022 –
“Data Binding Rules Vulnerability CVE-2022-22968” follow-up blog post published, related to the “disallowedFields” from the Suggested Workarounds
April 4, 2022 –
Am I Impacted with improved description of deployment requirements
April 2, 2022 –
Mend’s recommended actions to fix CVE-2022-22965 are below:
- Run an organization-wide inventory report. We have also created our free Spring4Shell Detect tool, which quickly scans your projects to find the vulnerable Spring4shell versions.
- Search the inventory report for libraries with instances of the referenced vulnerability to identify impacted applications.
- Contact relevant teams and alert them to the urgency of upgrading to the fix.
- Here are the different relevant fixes: Users of affected versions should apply the necessary mitigations and/or remediation:
- Mitigation Recommendations: See below.
- Remediation Recommendations: Mend Vulnerability Database If you are running Mend Enterprise with Renovate, it will identify and recommend a pull request with the latest version of the top-level affected package. Adding the linked Renovate configuration will include transitive dependencies.
April 1, 2022 – 16:35 BST
Am I Impacted with additional notes
April 1, 2022 – 13:05 BST
Workarounds section for Apache Tomcat upgrades and Java 8 downgrades
April 1, 2022 – 12:51 BST
Apache Tomcat releases versions 10.0.20, 9.0.62, and 8.5.78 which close the attack vector on Tomcat’s side, see mitigation alternative
March 31, 2022 – 4 PM BST
Spring Boot 2.6.6 is available
Spring Boot 2.5.12 is available
CVE-2022-22965 is published
Overview
The internet is abuzz with the disclosure of CVE-2022-22965, an RCE vulnerability in Spring, one of the most popular open-source frameworks for Java applications in use today. Known as “Spring4Shell” or “SpringShell”, the zero-day vulnerability has triggered widespread concern about the possibility of a wave of malicious attacks targeting vulnerable applications. Is this Log4j 2.0?
This is a developing event, and there is still some lack of clarity regarding the specifics of this vulnerability. The Mend research team is carefully observing developments and researching the case and will update this page and our Mend resources as we learn more.
Spring released an announcement regarding this vulnerability a few hours ago.
According to the announcement, CVE-2022-22965 affects Spring MVC (spring-webmvc) and Spring WebFlux (spring-webflux) when running on JDK 9 or above. In addition, the currently available exploit requires that the application be packaged as a WAR and deployed to Apache Tomcat. However, the Spring team emphasized that “the nature of the vulnerability is more general, and there may be other ways to exploit it”.
The vulnerability in Spring Beans allows attackers under certain circumstances to achieve remote code execution (RCE). Current PoC related to the attack is done by creating a specially crafted request which manipulates ClassLoader to successfully achieve RCE.
It is important to note that this is a separate case from CVE-2022-22963, which is related to Spring Cloud Function. In CVE-2022-22963, a malicious actor can provide a specially crafted SpEL as a routing-expression that may result in access to local resources. Again, CVE-2022-22963 is not Spring4Shell (CVE-2022-22965), and the two are not related. The confusion stems from the fact that both were disclosed at nearly the same time.
Mitigation Guidance
At present, VMWare has officially released a confirmed patch related to CVE-2022-22965 and we highly recommend upgrading your software to Spring Framework 5.3.18. A backported fix is also available for Spring Framework 5.2.20.
While these two releases address the vulnerability, the release process for Spring Boot is still in progress.
We recommend using the confirmed patch rather than the temporary patch announced earlier today, which is:
Temporary Solution 1: WAF Temporary Policy
On network protection devices such as WAF, according to the actual traffic situation of deployed services, the
“class.*“，”Class.*“，”*.class.*“，”*.Class.*”
and other string rules, and after deploying the filtering rules, test the business allowable conditions to avoid additional impact.
Temporary Solution 2: Temporary mitigation measures
April 13 – Before implementing this mitigation you should take into consideration the information shared in “Data Binding Rules Vulnerability CVE-2022-22968” follow-up blog post.
Create the following global class under the project package of the application system, and ensure that this class is loaded by Spring (it is recommended to add it in the package where the Controller is located). After the class is added, the project needs to be recompiled and packaged and tested for functional verification. and republish the project.
import org.springframework.core.annotation.Order;
import org.springframework.web.bind.WebDataBinder;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.InitBinder;
@ControllerAdvice
@Order(10000)
public class a{
@InitBinder
public void setAllowedFields(WebDataBinder dataBinder) {
String[] abd = new String[]{“class.*“, “Class.*“, “*.class.*“, “*.Class.*“};
dataBinder.setDisallowedFields(abd);
}
}
