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).
(Author of the OG Log4Shell post here)<p>I'm poking around at the Spring code and posting some notes about what I find on Twitter[0].<p>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.<p>0: <a href="https://twitter.com/LunaSecIO/status/1509084844042510336" rel="nofollow">https://twitter.com/LunaSecIO/status/1509084844042510336</a><p>EDIT:<p>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.<p>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.<p>1: <a href="https://github.com/lunasec-io/spring-rce-vulnerable-app" rel="nofollow">https://github.com/lunasec-io/spring-rce-vulnerable-app</a><p>2: <a href="https://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/" rel="nofollow">https://foxglovesecurity.com/2015/11/06/what-do-weblogic-web...</a>
On what basis does anyone think there is a 0 day here?<p>The commit just looks like sane defensive programming. Serialisation is a known source of RCEs, so they deprecate its use.
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.<p>Edit: They just translated the chinese post you can find linked here.<p>[1] <a href="https://github.com/spring-projects/spring-framework/pull/28075" rel="nofollow">https://github.com/spring-projects/spring-framework/pull/280...</a>
This was actually demented by one of the Spring developers.
<a href="https://github.com/BugAlertDotOrg/bugalert/pull/43#issuecomment-1082907298" rel="nofollow">https://github.com/BugAlertDotOrg/bugalert/pull/43#issuecomm...</a>
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.<p>How is this being upvoted without an actual POC and using language like “possible” and “may”?
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?
For some reason the link didnt work for me previously, so I linked to github. The notice can also be found at bugalert.org: <a href="https://bugalert.org/content/notices/2022-03-29-spring.html" rel="nofollow">https://bugalert.org/content/notices/2022-03-29-spring.html</a>
Previously I submitted a thread about this:<p><a href="https://news.ycombinator.com/item?id=30850400" rel="nofollow">https://news.ycombinator.com/item?id=30850400</a><p>However the original image is deleted from twitter.<p>If it is true, you will need to downgrade to JDK8. But to solve Log4J issue, you need JDK9+...