[culturedsystems]

I don't think there's any vulnerability in your repo as it is. It's not deserializing attacker controlled data, it's deserializing a string which was serialised by the application. There could be a vulnerability if, instead of accepting a String, the controller accepted some other class, which itself had custom serialisation logic which was vulnerable.

[freeqaz]

This is the pattern that's in the Spring code, which is why I wrote it there.

I agree with you though that it seems non-obvious.

My thought is that it's possible to build a payload that is able to go from "serialize(string) -> deserialize(string) -> object".

If it's possible to do that, then there is some possibility that there is an RCE here. But I'd still have to poke at the @CacheResult annotation to understand what a vulnerable usage would look like.

First thing is first though. Start with the simplest case. Prove or disprove exploitability before moving up the chain.

[dmharrison]

This doesn't look like a CVE based on this. To execute this you'd have to post in the class file, deserialise and then exec. All of this takes explicit additional code. This looks to be the same as any other language where you would let a user upload code and then just exec it, not something you really do accidentally and not part of core spring (I'm hoping). @Serializable is going to send the fields not the methods, so again you'd usually have deserialise to a known object which rehydrates, and then exec.

I struggle to see that usage in any std spring app which is going to use say jackson/json parsers typically and is hooked of content-type field which has to be mapped for usage really. If there's other vectors to trigger even with the object you'd still then have to invoke which would take additional explicit code. Using object deserialisation 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

[freeqaz]

Thanks for the detailed info about this! I'll go poke my head in on this again now that I'm awake and verify all of this. Some people are claiming POCs so I'm very curious to dig in!

Just because something is popular doesn't mean it's going to be bullet proof, btw. People miss stuff regularly like in log4j. Digging deep is where the juiciest bugs are found!

[culturedsystems]

The Spring code isn't restricted to strings, it will accept any type. So you don't need to find unsafe string serialisation to get an RCE; what you need is some type which is unsafe when deserializing the output of its own serialise function (and for an attacker controlled instance of this type to be passed to this Spring method)