Details of a zero-day vulnerability in Spring Framework were leaked on March 29, 2022 but promptly taken down by the original source. Although much of the initial speculation about the nature of the vulnerability was incorrect, we now know that the vulnerability has the potential to be quite serious depending on your organization’s use of Spring Framework. There is also a dedicated CVE 2022-22965 assigned to this vulnerability.
We will keep this blog updated as new information comes up.
Technical summary
Although the cause was initially rumored to be related to deserialization, the actual cause is due to unforeseen access to Tomcat’s ClassLoader as a result of the new Module feature added in Java 9. An existing mitigation only blocked access to the classLoader property of Class objects, but the new Module object also has a classLoader property and was therefore accessible through Spring’s property bindings when a Java object is bound to a request parameter.
Access to the classLoader property is then combined with a well-known method for performing an arbitrary file write using the Tomcat AccessLogValve class, potentially allowing an attacker to write a malicious JSP file accessible via the application server.
It is also important to note that the recently disclosed Spring Cloud vulnerability is not related to this particular flaw.
Who is impacted?
If you are using:
- Spring Web MVC or Spring Webflux projects AND
- Spring Framework version 5.3.x prior to 5.3.18, and all versions prior to 5.2.20 AND
- Java 1.9 or above AND
- Deployed on Tomcat App Server as a WAR AND
- Spring Web MVC with parameter binding (enabled by default) AND
- Do not have an allowlist of HTTP fields registered to be allowed or explicitly disallow fields which could cause malicious intent.
Mitigation
Please refer to the suggested workarounds as explained by Spring framework’s engineering team.
In summary, mitigate in the below order:
- Upgrade to the latest Spring Framework versions by changing your build files.
- If you can not upgrade, use one of the following DataBinder allow/disallow configurations ordered by level of effectiveness:
- Use an allowlist containing only properties that are expected from the requests
- Extend RequestMappingHandlerAdapter
- If you can not do a or b, apply a disallow list using @ControllerAdvice for a central configuration
- If you can not do a, b, or c, configure a disallow list in every single Controller
If using disallow list, it should include the below values:
“class. *”, “Class. *”, “* .class. *”, “* .Class. *”
How can we help?
Thanks to our Software Composition Analysis (SCA) product, you can quickly verify whether an application portfolio that you’s scanning with us contains the library needed to be affected by this vulnerability. Details can be found here.
References:
History:
|
31-MARCH-2022 |
Initial Version |
