Affects: Major and minor versions other than 5.3.x
Can we please have the PropertyDescriptor filtering commit https://github.com/spring-projects/spring-framework/commit/002546b3e4b8d791ea6acccb81eb3168f51abb15 backported to 4.x branches?
Comment From: rstoyanchev
@magJ are you on JDK 9+?
Comment From: 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.
Comment From: magJ
@rstoyanchev Yes, we have at least some projects that are using spring 4.x running on JDK 9+
Comment From: 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
Comment From: 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
Comment From: 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.
Comment From: 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).
Comment From: 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.
Comment From: 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.
Comment From: 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).
Comment From: 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.
Comment From: jhoeller
@rhanton That's the case indeed. The entire problem is tied to DataBinder as used for model attribute binding in MVC. With payload conversion (such as commonly done with JSON), there is no exposure to this vulnerability as far as we understand.
If you are even on an EOL branch of Tomcat, I'm really surprised that your operations team upgraded the JDK that far. Even a major Tomcat upgrade is usually a much lighter step to take than a JDK 9+ upgrade. We see plenty of systems on recent Spring and Tomcat versions but hanging on to JDK 8 instead.
In any case, we strongly recommend an upgrade to supported branches of Spring and Tomcat, or at least to a supported branch of one of them - otherwise there is no chance for vulnerabilities to be addressed from either side, not for this present case, not for other vulnerabilities from the past 15 months, and not for any upcoming cases either.
Comment From: marcelstoer
For all active branches of Tomcat, there will be patch releases shortly that close the attack vector on Tomcat's side
Do you happen to have a reference for this? I wasn't able to find any discussion or announcement yet.
Update Found it on their dev mailing list: https://markmail.org/search/?q=list%3Aorg.apache.tomcat.dev%2F+CVE-2022-22965+#query:list%3Aorg.apache.tomcat.dev%2F%20CVE-2022-22965%20+page:1+mid:z5y7spymskac3tez+state:results
Comment From: snicoll
@marcelstoer Did you check the Tomcat Dev list?
Comment From: rstoyanchev
Also the follow-up blog post with Tomcat version numbers.
Comment From: quaff
Removing org.apache.catalina.valves.AccessLogValve from Tomcat conf/server.xml is another alternative.
Comment From: rwinch
@quaff
Removing org.apache.catalina.valves.AccessLogValve from Tomcat conf/server.xml is another alternative.
Doing this prevents the exploit that has been circulating, but this is brittle because other properties on Tomcat internals can be set by an arbitrary user so I would not rely on this protecting your application.
Comment From: quaff
@quaff
Removing org.apache.catalina.valves.AccessLogValve from Tomcat conf/server.xml is another alternative.
Doing this prevents the exploit that has been circulating, but this is brittle because other properties on Tomcat internals can be set by an arbitrary user so I would not rely on this protecting your application.
I knew it, this is the most convenient workaround if you can't upgrade either spring or tomcat at the first time.