Backports for PropertyDescriptor filtering

[magJ]

Affects: Major and minor versions other than 5.3.x

---

Can we please have the PropertyDescriptor filtering commit 002546b backported to 4.x branches?

[rstoyanchev]

@magJ are you on JDK 9+?

[luozhenyu]

@magJ are you on JDK 9+?

@rstoyanchev Spring framework 4.3.x is widely used for years and some people upgrade JDK 8 to 11 to get better performance.

[magJ]

@rstoyanchev Yes, we have at least some projects that are using spring 4.x running on JDK 9+

[Artur-]

If this is not backported then we and and/or somebody else will be forced to fork Spring 4 and release a custom version. Does not sound tempting

[jhoeller]

Please note that Spring Framework 4.x was never officially supported on a JDK higher than 8, not in open source and not for commercial support arrangements either. The official support range is JDK 6-8: https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-Versions - running it on a newer JDK version is technically possible for certain scenarios, but anyone doing so has always been on their own in terms of support.

Also, Spring Framework 4.3.30 (the latest release before 4.x EOL) is on a December 2020 security patch level. Continued usage of that version misses out on 15 months of vulnerability patches and defensiveness measures that we applied to 5.x in the meantime. A patched version for the present CachedIntrospectionResults change would cover this particular attack vector on the unsupported JDK 9+ but might still keep you exposed to other vulnerabilities even in supported areas of the framework.

For older Spring versions, we strategically suggest an upgrade to 5.3.x, or tactically a workaround as suggested in our blog post: https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement

[luozhenyu]

Please note that Spring Framework 4.x was never officially supported on a JDK higher than 8, not in open source and not for commercial support arrangements either. The official support range is JDK 6-8: https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-Versions - running it on a newer JDK version is technically possible for certain scenarios, but anyone doing so has always been on their own in terms of support.

Also, Spring Framework 4.3.30 (the latest release before 4.x EOL) is on a December 2020 security patch level. Continued usage of that version misses out on 15 months of vulnerability patches and defensiveness measures that we applied to 5.x in the meantime. A patched version for the present CachedIntrospectionResults change would cover this particular attack vector on the unsupported JDK 9+ but might still keep you exposed to other vulnerabilities even in supported areas of the framework.

For older Spring versions, we strategically suggest an upgrade to 5.3.x, or tactically a workaround as suggested in our blog post: https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement

@jhoeller A bit disappointed but agree with you. I will upgrade to the latest version.

[Artur-]

For older Spring versions, we strategically suggest an upgrade to 5.3.x, or tactically a workaround as suggested in our blog post: https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement

Thanks, if the "workaround" is actually a solution that solves the problem for users of older versions then we can probably survive with that for the cases where an upgrade is not possible (because of good or bad reasons).

[rhanton]

@jhoeller Also disappointed here by disinterest in fixing this Critical severity issue. In our case, we do generally run apps as a separate war on tomcat and the only reason (to my chagrin) that I can't go to Spring 5.x is lack of support for the newer application server versions required from our operations engineers. Is my understanding here that the things I need to fear are POJO properties coming in as JSON objects with names like "class.*", "Class.*", "*.class.*", "*.Class.*" primarily?

I realize the security issues with doing so, but it'd be nifty if I had some POC exploit code I could try on existing applications to prove they are vulnerable or not.

[jhoeller]

@rhanton Are your operation engineers forcing you to stay on older versions of Tomcat? For all active branches of Tomcat, there will be patch releases shortly that close the attack vector on Tomcat's side (the resource exposure in the Tomcat ClassLoader) which will be a way to address the concerns for older (unpatched) versions of Spring. That said, please note that Spring Framework 4.x is nevertheless unsupported on JDK 9+; this is not a sensible operations arrangement to strategically stay on.

[rhanton]

@jhoeller in short - yes. But that's really good to hear that Tomcat is trying to patch this issue as well (sadly we're past-EOL there too).

[rhanton]

@jhoeller Am I right in understanding that this DataBinder CVE should be moot if you're not working with form submissions via @ModelAttribute? If all my data goes back and forth via RESTful JSON, it seems like DataBinder never gets called, but I may be incorrect with that assertion. Sorry it's been years since I dealt heavily with ModelAttributes.