How to resolve Spring RCE vulnerability(CVE-2022-22965)?

Question

Update

this issue is now assigned to CVE-2022-22965. Other than below nice answers, please do check Spring Framework RCE: Early Announcement as it is the most reliable and up-to-date site for this issue.

---

According to different source, seems we got a serious security issue when using Spring Core library.

• https://securityboulevard.com/2022/03/new-spring4shell-zero-day-vulnerability-confirmed-what-it-is-and-how-to-be-prepared/

Quoting from above link, we are in risk if:

• You use a Spring app (up to and including version 5.3.17) Your app runs on Java 9+
• You use form binding with name=value pairs – not using Spring’s more popular message conversion of JSON/XML
• You don’t use an allowlist –OR– you don’t have a denylist that blocks fields like “class”, “module”, “classLoader”

The link suggested to some solution but doesn't seems easy to implement/reliable. What should we do to fix this issue, in easiest and most reliable way?

Answer 1

According to the Spring Framework RCE: Early Announcement, upgrading to Spring Framework 5.3.18 or 5.2.20 will fix the RCE.

If you use Spring Boot, Spring Boot 2.5.12 and Spring Boot 2.6.6 fixes the vulnerability.

If you're unable to update:

You can choose to only upgrade Tomcat. The Apache Tomcat team has released versions 10.0.20, 9.0.62, and 8.5.78 all of which close the attack vector on Tomcat’s side.

If you can't do any of the above, the RCE announcement blog post suggests a workaround: Set disallowedFields on WebDataBinder through an @ControllerAdvice:

@ControllerAdvice
@Order(Ordered.LOWEST_PRECEDENCE)
public class BinderControllerAdvice {

    @InitBinder
    public void setAllowedFields(WebDataBinder dataBinder) {
         String[] denylist = new String[]{"class.*", "Class.*", "*.class.*", "*.Class.*"};
         dataBinder.setDisallowedFields(denylist);
    }

}

This quick fix will not work if a controller sets disallowedFields locally through its own @InitBinder method, which overrides the global setting. Also, more generally, the workaround will not have an effect if you use alternate REST frameworks such as Jersey (however, it has not yet been demonstrated that such configurations are impacted).