Spring Framework Remote Code Execution (CVE-2022-22965)

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 

The cause was initially rumored to be related to deserialization, but 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.  

Although the current exploit relies on a specific chain of accessible classes via Tomcat's ClassLoader, a chain that has been public since 2010 in the context of Struts vulnerabilities, it is possible that there are other exploitable classes accessible via the ClassLoader of other application servers. However, due to the fact that no alternative chains have been published in 12 years, it appears that the difficulty in developing an alternative exploit chain is rather high and as a result is unlikely, although not impossible.

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 9 Runtime Environment or above, regardless of the language version the application is compiled for  AND 
• Deployed on Tomcat App Server as a WAR AND 
• Spring Web MVC with parameter binding (enabled by default) AND 
• Don’t 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:

1. Upgrade to the latest Spring Framework versions by changing your build files. 
2. If you can’t upgrade, use one of the following DataBinder allow/disallow configurations ordered by level of effectiveness:  
   
   1. Use an allowlist containing only properties that are expected from the requests 
   2. Extend RequestMappingHandlerAdapter 
   3. If you can’t do a or b, apply a disallow list using @ControllerAdvice for a central configuration 
   4. If you can’t 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.*" 

Even if you aren’t impacted, upgrading to the latest Spring Framework version does address a security flaw and could prevent future unidentified exploit conditions. You should always plan on staying up-to-date with security patches used by any components in your system. So even if you don’t require an emergency patch for this vulnerability it should be planned soon.

How Veracode can help 

Thanks to our Software Composition Analysis (SCA) product, you can quickly verify whether an application portfolio that you’re scanning with us contains the library needed to be affected by this vulnerability. Details can be found here. 

References: 

• Spring Framework RCE Announcement 
• Github link for Spring4Shell-POC  
• Researcher’s blog 

History: