spring-framework

ne.first.suffix=.jsp This will access the `class` object and uses the `getModule` method of the `Class` object to get the `Module` class. Now, this class has the `ClassLoader` exposed via a getter BUT it's exposed as opposed to the `Class` class[4]! In the POC, it's an instance of `WebAppClassLoaderBase` (when using Tomcat, under some circumstances). This class has a `getResources` method that is accessed here, along with `getContext`, `getParent`, etc. all the way up to the last delimiter which invoke the `setSuffix` method of the `AccessLogValve` instance [5]. Rinse and repeat this to set the tone for the JSP vulnerability and you have a RCE. Now, this needs some specific preconditions. However, there are probably hundred of other mutable objects accessible this way that could lead to pretty nasty bugs, vulnerability of information disclosures. Finally, I can confirm that the workaround with `@InitBinder` mentioned in [6] works. EDIT : Looks like a regression from CVE-2010-1622 that was fixed in [7]. [0] https://docs.spring.io/spring-framework/docs/3.2.x/spring-fr... [1] https://gist.github.com/jebeaudet/127e6fb0b59e06c0642d2f362e... [2] https://github.com/spring-projects/spring-framework/blob/mai... [3] https://www.cyberkendra.com/2022/03/spring4shell-details-and... [4] https://github.com/spring-projects/spring-framework/blob/mai... [5] https://github.com/Oreste-Luci/apache-tomcat-8.0.26-src/blob... [6] https://www.cyberkendra.com/2022/03/springshell-rce-0-day-vu... [7] https://github.com/spring-projects/spring-framework/commit/3...

app root directory, which can then be used to get a shell. It looks like this issue is only exploitable if your app is deployed as a war file. [0]: https://github.com/TheGejr/SpringShell/blob/master/Vulnerabi... [1]: https://github.com/fengguangbin/spring-rce-war [2]: https://github.com/spring-projects/spring-framework/blob/mai...

serialisation would be pretty uncommon (ie non existent) hooked up to http stack. Json, XML, yaml parsers etc are different libs. To get this to CVE you'd have to trigger this automatically somehow through the spring request processing stack and then say invoke the object with vulnerabilities in java's core deserialisation libs which I'm assuming is relatively solid and verified given it's key role in java, see java security manager in jvm for actions like dynamic class loading etc. From https://github.com/spring-projects/spring-framework/pull/280... "The core Spring Framework does not use SerializationUtils to deserialize objects from untrusted sources." They talk about use against a cache but again rule out CVE. For this to get to CVE issue it would be if there was a vector where spring can take a request with a class file/location eg urlclassloader bypass a bunch of security checks and get it to run, which again java security manager will not allow typically. As it stands in the bug, that's not called out as a vector and more of a don't do silly things, sure we'll mark it as deprecated tone. There may be something somewhere else, but as it stands I read this issue as don't exec untrusted code in your webapp which should be true in any language. Your example is explicitly coding to do this, not something any typical spring app does. I guess use cases like job interview, code testing tools might do this. but it's still going to be execing against a specific interface/abstraction typically on the server side, ie still not unknown code. Ie the methods live in server side classes that correspond to the type the serialised class is deserialised to, no code transmitted so can't inject behaviour simply by deserialising