CVE-2016-1000027 -- alternative approach

[baiadrandy]

We have an incredible amount of customers that complain about this CVE and the response from here is to force everyone to jump to JDK 17.
OR to tell all our customers that trust Spring, this CVE is not an issue because it is deprecated and trust us that we are not calling this.
Well, that really doesn't cut the mustard with a lot of our customers and switching all of our code to JDK 17 is not a quick job.

What about this?

If you produce an alternative spring-webEX.jar that has those vulnerable classes removed?
Then for all those developers that don't want to justify why we ship code with this CVE, they will exclude the original spring-web and depend on spring-webEX.

For all projects that rely on those deprecated classes can still use spring-web, but for those others that don't want that CVE and CANT go to JDK 17, you provide a solution.

I hope you can appreciate the dilemma we are in.

Sincerely,

Randy

[bclozel]

Duplicates #24434

This solution has been discussed already and this is not a sustainable approach. Ignoring the CVE by configuring tools (after assessing the apps) and pressuring vendors is still the best choice right now. Again, the official MITRE entry is not scored and is only meant for documentation purposes. The fact that the NVD chose to score it (and how...) is totally unrelated unfortunately. The GitHub entry on the other hand is quite well documented: GHSA-4wrc-f8pq-fpqp

In a way, this issue remains with modern Spring versions as you don't need any Spring class to be vulnerable to this.

[baiadrandy]

Duplicates #24434

This solution has been discussed already and this is not a sustainable approach. Ignoring the CVE by configuring tools (after assessing the apps) and pressuring vendors is still the best choice right now. Again, the official MITRE entry is not scored and is only meant for documentation purposes. The fact that the NVD chose to score it (and how...) is totally unrelated unfortunately. The GitHub entry on the other hand is quite well documented: GHSA-4wrc-f8pq-fpqp

In a way, this issue remains with modern Spring versions as you don't need any Spring class to be vulnerable to this.

Could you remove the Spring remoting package from the spring-web artifact and call this Spring-WebEX?
Wont that address this issue if we dont rely on those classes? This way HTTPInvoker is not even there?

[bclozel]

This is not a sustainable approach. Not only this sets a precedent for other CVEs, but this also asks a lot of practical questions for our ecosystem in general.
This means that all other Spring projects and libraries would need to depend on that new dependency, not the usual spring-web one. Otherwise consumers would need an elaborate exclusion system for lots of dependencies. Having both on the classpath with possibly different versions will create problems as well.

Finally, changing our position here so late in the 5.3.x generation will only create uncertainty and will add credibility to this report. For the sake of the community we should improve the CVE process, not reward bad behavior.

[jdomigon]

I acknowledge I'm late in this discussion and that the issue seems a bit "heated" by now.

Just another idea: an alternative option instead of removing the Spring remoting package could be disabling in runtime the instantiation of the vulnerable classes unless a well-known system property (or a similar mechanism) is set.

[bclozel]

@jdomigon it's not heated at all. Spring Framework 5.3.x and 6.0.x generations are both out of OSS support.

This means that unless you are a commercial customer getting commercial releases, you are depending on a 5.3.x or 6.0.x release that is vulnerable to other, actual and actionable CVEs.