WingNews logo WingNews GitHub [2]
top | item 30851919

Possible Spring core RCE

61 points| chillax | 4 years ago |github.com | reply

35 comments

order
[+] makomk|4 years ago|reply
Seems unlikely. The commit this speculates is the fix for the supposed RCE does not appear to change the behaviour of Spring in any way - it just refactors some code into a seperate function, adds a unit test for that function, and marks the use of serialization-related functions as depreciated due to their history of RCE issues. The apparent reason for the refactoring is to avoid triggering the depreciation warning for one particular use of serialization which should be safe (it serializes and then immediately deserializes a non-attacker-controlled object).
[+] freeqaz|4 years ago|reply
(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

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

2: https://foxglovesecurity.com/2015/11/06/what-do-weblogic-web...

[+] Copenjin|4 years ago|reply
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

[1] https://spring.io/blog/2022/03/29/cve-report-published-for-s...

[2] https://github.com/spring-projects/spring-framework/pull/280...

[+] culturedsystems|4 years ago|reply
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.
[+] mhio|4 years ago|reply
What is the OG Log4Shell post?
[+] MattPalmer1086|4 years ago|reply
On what basis does anyone think there is a 0 day here?

The commit just looks like sane defensive programming. Serialisation is a known source of RCEs, so they deprecate its use.

[+] Copenjin|4 years ago|reply
The blog post on Kendra looks like a draft hoping for an actual confirmation/poc to come up, the mitigation just explains manually how to replicate the PR #28075.

Edit: They just translated the chinese post you can find linked here.

[1] https://github.com/spring-projects/spring-framework/pull/280...

[+] nikeee|4 years ago|reply
A comment [0] on the commit of that PR points to this site [1]. This site mentions that the vulnerability is similar to CVE-2010-1622 [2, 3]. Maybe this could help finding the issue, toegether with the recommended actions and mentioned classes (CachedIntrospectionResults, CacheResultInterceptor).

[0]: https://github.com/spring-projects/spring-framework/commit/7...

[1]: https://mp.weixin.qq.com/s/P-NEJzUUjIyemkSe_RbicQ

[2]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1622

[3]: https://www.exploit-db.com/exploits/13918

[+] vips7L|4 years ago|reply
I don’t see how the linked code is an RCE. The deserialization function is used on trusted input from an object that is already in memory.

How is this being upvoted without an actual POC and using language like “possible” and “may”?

[+] topspin|4 years ago|reply
"How is this being upvoted without an actual POC and using language like “possible” and “may”?"

I appreciate being made aware of the speculation given the ubiquity of Spring. Those that claim an RCE in core Spring would be an order of magnitude worse than Log4Shell aren't wrong.

[+] MrBuddyCasino|4 years ago|reply
Can't tell if this depends on certain user code - does one have to use SerializationUtils or JCache explicitly in order to be vulnerable, or does the vulnerability exist by default?
[+] freeqaz|4 years ago|reply
That's my take on it from reading so far. That's a massive mitigating factor for exploitation, imo.

Log4Shell was painful because people were using the library as it was intended to be used (a logger takes strings that are possibly attacked controllable). This will not be as bad simply because it won't be easily exploitable to the same degree.

[+] TeeWEE|4 years ago|reply
Where is the explanation that serialize / deserialize has a RCE bug?
[+] ammo1662|4 years ago|reply
Previously I submitted a thread about this:

https://news.ycombinator.com/item?id=30850400

However the original image is deleted from twitter.

If it is true, you will need to downgrade to JDK8. But to solve Log4J issue, you need JDK9+...

[+] MattPalmer1086|4 years ago|reply
You can fix log4j in Java 8. But you do need to have extended support for it so you actually get security fixes in general.
[+] formerly_proven|4 years ago|reply
Java and trivially exploitable RCE are certainly believable.
[+] chockchocschoir|4 years ago|reply
Java doesn't make exploitable RCEs more or less possible than any other programming language. Or do you have something to back this up beyond the common "Java be bad" trope?