4 ms·

(Author of the OG Log4Shell post here) I'm poking around at the Spring code and posting some notes about what I find on Twitter[0]. I'm not a Java expert so i

(Author of the OG Log4Shell post here) I'm poking around at the Spring code and posting some notes about what I find on Twitter[0]. I'm not a Java expert so if anybody feels like chiming in to help connect the dots for others, please feel free. It's late over here so I'm just doing my best to help determine if this is a real problem or just fear mongering. 0: https://twitter.com/LunaSecIO/status/1509084844042510336 https://twitter.com/LunaSecIO/status/1509084844042510336 EDIT: I wrote a basic vulnerable app on GitHub[1] that is helpful for finding the most "simple" payload that could trigger this RCE. If anybody with better Java skills than myself would be willing to poke at this for a sec, that'd be super appreciated. I was using this guide[2] with the ysoserial section to generate a deserialzation payload for this. I still don't have enough Java-fu to understand how to get that to fire though, and it's 3am so my brain is shot. Perhaps with these pointers somebody else can figure out that part to help sort out the impact around this possible RCE. 1: https://github.com/lunasec-io/spring-rce-vulnerable-app https://github.com/lunasec-io/spring-rce-vulnerable-app 2: https://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ https://foxglovesecurity.com/2015/11/06/what-do-weblogic-web...

mhio 5y ago
What is the OG Log4Shell post?
- hashhar 5y ago
  https://www.lunasec.io/docs/blog/log4j-zero-day/ https://www.lunasec.io/docs/blog/log4j-zero-day/ By LunaSec IIRC.
culturedsystems 5y ago
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 5y ago
  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 5y ago
    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/28075 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
Copenjin 5y ago
It looks like they are mixing it up with CVE-2022-22963 related to spring cloud[1] from a few days ago and one of the members of the Spring project is reporting that there is no vulnerability associated with the deserialization fix everyone (the chinese OP, the eng posts) is referring to. https://twitter.com/Ax_Sharma/status/1509103877978824707 https://twitter.com/Ax_Sharma/status/1509103877978824707 [1] https://spring.io/blog/2022/03/29/cve-report-published-for-spring-cloud-function https://spring.io/blog/2022/03/29/cve-report-published-for-s... [2] https://github.com/spring-projects/spring-framework/pull/28075 https://github.com/spring-projects/spring-framework/pull/280...

mhio 5y ago

What is the OG Log4Shell post?

hashhar 5y ago
https://www.lunasec.io/docs/blog/log4j-zero-day/ https://www.lunasec.io/docs/blog/log4j-zero-day/ By LunaSec IIRC.

culturedsystems 5y ago

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 5y ago
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 5y ago
  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/28075 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

Copenjin 5y ago

It looks like they are mixing it up with CVE-2022-22963 related to spring cloud[1] from a few days ago and one of the members of the Spring project is reporting that there is no vulnerability associated with the deserialization fix everyone (the chinese OP, the eng posts) is referring to. https://twitter.com/Ax_Sharma/status/1509103877978824707 https://twitter.com/Ax_Sharma/status/1509103877978824707 [1] https://spring.io/blog/2022/03/29/cve-report-published-for-spring-cloud-function https://spring.io/blog/2022/03/29/cve-report-published-for-s... [2] https://github.com/spring-projects/spring-framework/pull/28075 https://github.com/spring-projects/spring-framework/pull/280...