6 ms·

Possible Spring core RCE

61 points by chillax 5y ago

MattPalmer1086 5y ago
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.
TeeWEE 5y ago
Where is the explanation that serialize / deserialize has a RCE bug?
chillax 5y ago
For some reason the link didnt work for me previously, so I linked to github. The notice can also be found at bugalert.org: https://bugalert.org/content/notices/2022-03-29-spring.html https://bugalert.org/content/notices/2022-03-29-spring.html
- cotillion 5y ago
  This appears to be some Chinese source with the same info: https://cn-sec.com/archives/853339.html https://cn-sec.com/archives/853339.html Looking at Github and uses of SerializationUtils.deserialize this is going to be painful.
formerly_proven 5y ago
Java and trivially exploitable RCE are certainly believable.
- chockchocschoir 5y ago
  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?
  - formerly_proven 5y ago
    Java certainly has a long history of RCEs caused by Java Serialization.
    - chockchocschoir 5y ago
      Comparing Java Serialization with $language Serialization, and the usage of both of the languages, does Java have more RCEs per line written than $language? Or is it just a function of its popularity?
      - xmodem 5y ago
        The java ecosystem has a frustrating habbit of solving problems with java's lack of expressiveness with layers of expression and templating languages, and has had some nasty RCE's as a result. (see: OGNL, freemarker) I don't know if it's better or worse than other languages but let's not pretend it's not a problem.
- Traubenfuchs 5y ago
  As compared to which language that does it significantly better? https://www.sourceclear.com/vulnerability-database https://www.sourceclear.com/vulnerability-database Everything is a mess, no matter the language.
ammo1662 5y ago
Previously I submitted a thread about this: https://news.ycombinator.com/item?id=30850400 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+...
- albertopv 5y ago
  Or not use Log4J at all.
- MattPalmer1086 5y ago
  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.
  - andylynch 5y ago
    Why would you need extended support for Java 8 to deploy a log4j patch? Oracle will happily take the money I’m sure but the log4j update is freely downloadable from Apache.
    - MattPalmer1086 5y ago
      You don't. You need extended support to get security patches in general, not for log4j. Different issues, sorry I wasn't clear.
  - vbezhenar 5y ago
    There are many Java 8 builds. Use azul.
MrBuddyCasino 5y ago
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 5y ago
  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.
deleted 5y ago
[deleted]
Copenjin 5y ago
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/28075 https://github.com/spring-projects/spring-framework/pull/280...
- nikeee 5y ago
  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/7f7fb58dd0dae86d22268a4b59ac7c72a6c22529#r69860640 https://github.com/spring-projects/spring-framework/commit/7... [1]: https://mp.weixin.qq.com/s/P-NEJzUUjIyemkSe_RbicQ https://mp.weixin.qq.com/s/P-NEJzUUjIyemkSe_RbicQ [2]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1622 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1622 [3]: https://www.exploit-db.com/exploits/13918 https://www.exploit-db.com/exploits/13918
vips7L 5y ago
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 5y ago
  "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.
freeqaz 5y ago
(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.
deleted 5y ago
[deleted]
makomk 5y ago
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).
- richbell 5y ago
  It's been confirmed since yesterday morning and is now officially recognized by Spring. https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement https://spring.io/blog/2022/03/31/spring-framework-rce-early...
annnoo 5y ago
This was actually demented by one of the Spring developers. https://github.com/BugAlertDotOrg/bugalert/pull/43#issuecomment-1082907298 https://github.com/BugAlertDotOrg/bugalert/pull/43#issuecomm...
- gred 5y ago
  > demented You're probably looking for "denied".

61 points by chillax 5y ago

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.

TeeWEE 5y ago

Where is the explanation that serialize / deserialize has a RCE bug?

chillax 5y ago

For some reason the link didnt work for me previously, so I linked to github. The notice can also be found at bugalert.org: https://bugalert.org/content/notices/2022-03-29-spring.html https://bugalert.org/content/notices/2022-03-29-spring.html

cotillion 5y ago
This appears to be some Chinese source with the same info: https://cn-sec.com/archives/853339.html https://cn-sec.com/archives/853339.html Looking at Github and uses of SerializationUtils.deserialize this is going to be painful.

formerly_proven 5y ago

Java and trivially exploitable RCE are certainly believable.

chockchocschoir 5y ago
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?
- formerly_proven 5y ago
  Java certainly has a long history of RCEs caused by Java Serialization.
  - chockchocschoir 5y ago
    Comparing Java Serialization with $language Serialization, and the usage of both of the languages, does Java have more RCEs per line written than $language? Or is it just a function of its popularity?
    - xmodem 5y ago
      The java ecosystem has a frustrating habbit of solving problems with java's lack of expressiveness with layers of expression and templating languages, and has had some nasty RCE's as a result. (see: OGNL, freemarker) I don't know if it's better or worse than other languages but let's not pretend it's not a problem.
Traubenfuchs 5y ago
As compared to which language that does it significantly better? https://www.sourceclear.com/vulnerability-database https://www.sourceclear.com/vulnerability-database Everything is a mess, no matter the language.

ammo1662 5y ago

Previously I submitted a thread about this: https://news.ycombinator.com/item?id=30850400 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+...

albertopv 5y ago
Or not use Log4J at all.
MattPalmer1086 5y ago
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.
- andylynch 5y ago
  Why would you need extended support for Java 8 to deploy a log4j patch? Oracle will happily take the money I’m sure but the log4j update is freely downloadable from Apache.
  - MattPalmer1086 5y ago
    You don't. You need extended support to get security patches in general, not for log4j. Different issues, sorry I wasn't clear.
- vbezhenar 5y ago
  There are many Java 8 builds. Use azul.

MrBuddyCasino 5y ago

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 5y ago
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.

deleted 5y ago

[deleted]

Copenjin 5y ago

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/28075 https://github.com/spring-projects/spring-framework/pull/280...

nikeee 5y ago
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/7f7fb58dd0dae86d22268a4b59ac7c72a6c22529#r69860640 https://github.com/spring-projects/spring-framework/commit/7... [1]: https://mp.weixin.qq.com/s/P-NEJzUUjIyemkSe_RbicQ https://mp.weixin.qq.com/s/P-NEJzUUjIyemkSe_RbicQ [2]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1622 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1622 [3]: https://www.exploit-db.com/exploits/13918 https://www.exploit-db.com/exploits/13918

vips7L 5y ago

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 5y ago
"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.

freeqaz 5y ago

(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.

deleted 5y ago

[deleted]

makomk 5y ago

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).

richbell 5y ago
It's been confirmed since yesterday morning and is now officially recognized by Spring. https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement https://spring.io/blog/2022/03/31/spring-framework-rce-early...

annnoo 5y ago

This was actually demented by one of the Spring developers. https://github.com/BugAlertDotOrg/bugalert/pull/43#issuecomment-1082907298 https://github.com/BugAlertDotOrg/bugalert/pull/43#issuecomm...

gred 5y ago
> demented You're probably looking for "denied".