10 ms·

Spring Core on JDK9 is vulnerable to remote code execution

157 points by groundshark 4y ago

mbfg 4y ago
Fortunately very few companies of any size use jdk9+
- EdwardDiego 4y ago
  Unfortunately you're wrong. While some companies haven't yet made the leap from 8 to 11, most have. You'll find that Java 8 support is being deprecated if not outright removed across the JVM ecosystem.
  - krzyk 4y ago
    I would say fortunately. Oracle premier support for JDK 8 ends today.
  - mbfg 4y ago
    Can you point me to surveys to back up this claim? I interview lots of people from lots of companies, no one is using anything above java 8. Sure this evidence is anecdotal, but i've probably got evidence from around 150 companies.
    - EdwardDiego 4y ago
      Nothing I can share, sorry.
groundshark 4y ago
Possible 0-day RCE impacting Spring applications.
- EdwardDiego 4y ago
  Possible...
olliej 4y ago
Looks like another "I'm in a 'safe' language, so can do unsafe things" crossed with the standard object deserialization error of default allowing any class to be instantiated. The temporary fix that they list seems to imply that the current APIs don't allow specifying a finite list of allowed classes?
- dboreham 4y ago
  Any kind of writable reflection facility, and any kind of eval() should be added to the set of "unsafe" features.
  - hsbauauvhabzb 4y ago
    At some point, mvc frameworks have to do some magic to dynamically load classes. This should be done at runtime, but can’t imagine it’s an easy problem to solve.
    - richbell 4y ago
      Frameworks like Quarkus and Micronaut do this at compile time. They dynamically load things and record it, then insert the resulting bytecode statically in the build artifact. I believe the core motivator is performance, but it has the added benefit of eliminating most of the runtime magic that leads to vulnerabilities like this.
    - dboreham 4y ago
      Not my field, but how can this be so? We had MVC in 1990 written in C or C++.
      - olliej 4y ago
        In principle I think you could do something like this with COM, but I’m unaware of any such framework
    - olliej 4y ago
      No they don’t, MVC has existed in C++ for decades. The problem is specific to reflection based MVC frameworks (objc has similar issues). The solution is to explicitly specify every class that can be instantiated at compile time. Similar to how modern deserialization frameworks work. No code should be written that allows content from the network to explicitly specify arbitrary code to load and execute. E.g having a packet say <view class=“MyView”> and feeding the string “MyView” into some classloader, or dlsym, or whatever is asking for trouble. Feeding it into switch (view.class) { case “MyView”: return new MyView() … } Results in a much less powerful primitive
scanr 4y ago
“This vulnerability allows an unauthenticated attacker to execute arbitrary code on the target system.”. Interesting that the CVE has been around for so long.
skered 4y ago
JDK9+? Not just 9.
- rlevy 4y ago
  Yes
invokestatic 4y ago
I am still deeply skeptical that this exploit really exists, or if it does, it is extremely exaggerated. I can’t really articulate the reasons why. Part of it is the fact that a lot of the people reporting on it self-admit that they are unfamiliar with Java and Spring. One “PoC” repo I’ve seen is just simple API misuse. API misuse is a CVE in the application that does the misusing, NOT the library that is misused (in this case spring). Something else is that very soon after there was a /hint/ of a log4j exploit, we saw rapid and evolving exploitation in the wild. We have nothing like that happening now, since this news first broke, what, 12 hours ago? Then there’s also the suspicion where I feel the LunaSec people, one of the first groups to report on this, are desperately trying to re-catch the fire they caught when they first reported log4j. I’m sure that was amazing for marketing their company. Problem is, I think reporting on this before there is really indication of a real issue reduces the credibility of them as competent security researchers. Of course, I may come back to eat my words.
- freeqaz 4y ago
  LunaSec founder here. I can understand the suspicion. It's the right mindset to have when looking at CVEs, in general, because 99% of them are overblown. The first title I wrote for the blog post was "There is no vuln" but I was wrong. Only after I spent a few hours digging did my gut change my mind. In this case I wrote the post to discuss 2 different vulns. One was a confirmed RCE with a CVE and the other was a WIP with only sketchy Twitter screenshots to go on. That alone was confusing many people and was the reason many people were posting about finding an "RCE POC" without realizing they were talking about the wrong vuln. That was the primary reason that we (LunaSec) wrote the original post -- to help people understand that there were 2 vulns and that they needed to be careful to confirm which they were discussing. There was too much unwarranted hype, too much confusion, and too little "real" information to prove/disprove if an exploit was possible. That said, at some point as researchers, we have to trust our gut about potential impact and exploitability without full knowledge of the vuln. With Log4Shell, when we wrote that post, we hadn't personally proven that the JNDI vulnerability could be exploited. It just felt like a matter of time before it would be figured out by somebody much smarter that us. And with this exploit and the people discussing it, it felt like there was likely something there (which has turned out to be true, retroactively). So that's the line, as researchers, that we have to balance by attempting to provide an "early warning" for companies/devs while also not just sitting for days with the vulnerable code (in this case Spring) to prove out an exploit until a bunch of blackhats already move on to mass exploitation. Anyway, at this point, people that I trust a lot have come forward to say that they were able to verify the exploit with a POC themselves. Specifically, @pwntester has tweeted about this[0][1] confirming that he's been able to get an exploit. He's a very good Java dev that is much, much faster than myself or anybody else on my team. -------- In this case, I noticed some people talking about it on Twitter and tried to put together info to help people "prove out" a POC with a "basic vulnerable app". Then I went to bed and looked at this again. That's when I realized that this was very confusing because there were multiple vulns being conflated in different libs. And then the Spring devs said that this wasn't an issue, but it very much still felt like there was the possibility for an exploit still. It turned out to be "Class Loader Manipulation" instead of "Deserialization injection" but the activity relating to this on Twitter was real. I sat with my engineers for several hours just poking at getting a POC working and we're very confident that, with a little more time, we'll be able to turn this into a POC like the Struts one. We're just not Java guys so it's slow. Getting a debugger takes time, understanding Spring takes time, etc. There are much more competent devs and researchers out there than us -- we're just trying to reduce the uncertainty and misinformation in a way that helps companies patch faster. Communicating clearly about hard technical subjects while also writing POCs on-the-fly is difficult, and I apologize if what I wrote came across as more "corporate shill" than "security researcher trying to reduce entropy". That's on me! 0: https://twitter.com/pwntester/status/1509240072301912074 https://twitter.com/pwntester/status/1509240072301912074 1: https://twitter.com/pwntester/status/1509248853614239747 https://twitter.com/pwntester/status/1509248853614239747 EDIT: Clarified some text
freeqaz 4y ago
(Author that named "Log4Shell" here) FYI, this is confusing because there are 2 different RCEs that have been published within the last 24 hours. One has a CVE and the other doesn't. OP's post by Praetorian is discussing the RCE dubbed "Spring4Shell". It's the RCE without a CVE yet, hence the name, and it affects Spring Core. It's likely fairly widespread/severe, but the "mitigating details" are still unknown. That said, it's very similar to the Apache Struts vuln that popped EquiFax a few years ago. (a Class Loader Manipulation exploit) So there is already some tooling available to weaponize it. The other RCE affects Spring Cloud Function and has been given CVE-2022-22963. We wrote a post[0] with info on both CVEs that references this Praetorian post under the "Remediation" section. We also added more information about the exploit scenarios to help push the ball forward for determining how widely exploitable this is going to be. (There is a 3rd possible one too, but it's still unconfirmed.) Basically, the authors of Spring Core tweeted[1] that there wasn't a vuln and that has added to the chaos of this. There is a vuln here. It's not as bad as Log4Shell, but it's still bad and likely widely exploitable given how popular Spring Core is and how some Java devs[2] have confirmed that the exploitable configuration is a "common pattern" in real-world usage. With the vuln there are more steps required for exploitation. That means kids on Minecraft won't be griefing each other with it, but that won't stop the blackhats from weaponizing this quickly. After all, this is a very similar attack to previous ones in Struts[3]. So if you're using Spring Core or Spring Cloud Function, it's a good idea to stay up-to-date on this stuff because it's moving pretty quick. If you already looked earlier this morning, a lot has changed (like this Praetorian post). It'll be a fun weekend for security teams everywhere! 0: https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/ https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/ 1: https://twitter.com/hacksilon/status/1509117953064812547 https://twitter.com/hacksilon/status/1509117953064812547 2: https://twitter.com/pwntester/status/1509298152691671046 https://twitter.com/pwntester/status/1509298152691671046 3: https://www.exploit-db.com/exploits/33142 https://www.exploit-db.com/exploits/33142
- smrtinsert 4y ago
  I have never seen that class SerializationUtils used in the wild. Now if it was in Jackson...
WatchDog 4y ago
There is a lot of bad information out there about this issue. What I have gathered so far, is that this is actually a real problem, but it may not affect most configurations. This[0] seems to be the original vulnerability analysis, and this is the example vulnerable app[1]. The main issue seems to be, that since java 9, WebDataBinder can be abused to access the classloader via the "class.module.classloader", you might think that "class.classloader" would work, but it's explicitly filtered out[2], it seems they need to add some filtering for module, as well. The proof of concept, then access the "AccessLogValve" class via "class.classLoader.resources.context.parent.pipeline.first", which is only accessible if the application is running using a "WeappClassLoaderBase", it then configures the logger, to output an arbitrary JSP file to the webapp root directory, which can then be used to get a shell. It looks like this issue is only exploitable if your app is deployed as a war file. [0]: https://github.com/TheGejr/SpringShell/blob/master/Vulnerability%20Analysis%20%5BCHINESE%5D.pdf https://github.com/TheGejr/SpringShell/blob/master/Vulnerabi... [1]: https://github.com/fengguangbin/spring-rce-war https://github.com/fengguangbin/spring-rce-war [2]: https://github.com/spring-projects/spring-framework/blob/main/spring-beans/src/main/java/org/springframework/beans/CachedIntrospectionResults.java#L291 https://github.com/spring-projects/spring-framework/blob/mai...
- awirth 4y ago
  If you can access the classloader that's pretty bad, it's likely people will find other gadgets. It's insane to me though that class.* isn't completely disallowed. What is the legitimate use case for deserializing allowing web requests to call setters in the reflection API? Also, agree it is impressive to me how much bad information I've seen.
  - loginatnine 4y ago
    Yea it didn't help that this was posted a bit after 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... and that the original article mentioned a commit on the class `SerializationUtils` which in the end has no connection to this. I believe accessing the `class` object here is a mistake. You can see my analysis here where I trace the POC https://news.ycombinator.com/item?id=30862953 https://news.ycombinator.com/item?id=30862953 but like you said, there are other problematic code paths for sure with this.
tauwauwau 4y ago
Not sure why it's tagged JDK9+, but 'class' attribute is accessible on org.springframework.beans.BeanWrapperImpl.getLocalPropertyHandler() in JDK 8 also. It probably doesn't matter which JDK is being used, as long as this spring-beans dependency is used. Whether logging JSP exploit in JDK 8 or lower can be used is another question. However, since 'class' is accessible via request parameter, it's already bad and there will probably be some ways to exploiting it. It doesn't matter whether the request is GET or POST, as long as mapped controller method uses a non-primitive request object, 'class' can be accessed. 'class.module' attribute is accessible from Java 9 and above, I tested on Java 11 and can access 'class.module'. Sample code that I used to test this with JDK 8 is below. I just tested whether 'class' attribute can be accessed via request parameter. curl -X POST localhost:8080/test?class.modifiers=Hello package com.test; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.web.bind.annotation.PostMapping; import org.springframework.web.bind.annotation.RestController; @SpringBootApplication public class Spring4ShellTestApplication { public static void main(String[] args) { SpringApplication.run(Spring4ShellTestApplication.class, args); } } @RestController class TestController { @PostMapping("/test") public String test(TestOuterRequest request) { String message = "Inner request is null"; if (request.getInnerRequest() != null) { message = "your message was: " + request.getInnerRequest().getMessage(); } System.out.println(message); return message; } } class TestOuterRequest { private TestInnerRequest innerRequest; public TestInnerRequest getInnerRequest() { return innerRequest; } public void setInnerRequest(TestInnerRequest innerRequest) { this.innerRequest = innerRequest; } } class TestInnerRequest { private String message; public String getMessage() { return message; } public void setMessage(String message) { this.message = message; } } Finally here are the attributes that're exposed on 'class' as accessible properties in JDK 8 (JDK9+ adds 'module' on top of all these) annotatedInterfaces annotatedSuperclass annotation annotations anonymousClass array canonicalName class classes componentType constructors declaredAnnotations declaredClasses declaredConstructors declaredFields declaredMethods declaringClass enclosingClass enclosingConstructor enclosingMethod enum enumConstants fields genericInterfaces genericSuperclass interface interfaces localClass memberClass methods modifiers name package primitive signers simpleName superclass synthetic typeName typeParameters
toyg 4y ago
Title should be fixed to say 9+ (as in the original source). I initially discounted the issue because v9 was a somewhat-experimental release that very few people ever ran in production; but later versions were mainstream, and if they are all vulnerable, then this is a major problem.
Copenjin 4y ago
Official announcement, a better remediation is proposed: https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement https://spring.io/blog/2022/03/31/spring-framework-rce-early... A new spring release should come out today.
hrpnk 4y ago
https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement https://spring.io/blog/2022/03/31/spring-framework-rce-early... "[11:59 BST] Spring Framework versions 5.3.18 and 5.2.20, which address the vulnerability, are now available on Maven Central. The release process for Spring Boot is in progress, but applications can already upgrade their Spring Framework version independently in order to be protected."
trollied 4y ago
Spring have blogged about it. Releases are on the way: https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement https://spring.io/blog/2022/03/31/spring-framework-rce-early...
alipitch 4y ago
Are there any data binding libraries (deserialization, marshaling, pickling libraries) that do not have the class of weaknesses as the two CVEs (CVE-2022-22965, CVE-2010-1622)? My understanding is as follows. - Spring uses WebDataBinder [0]. -> CVEs: CVE-2022-22965 (Spring4Shell), CVE-2010-1622 -> CVE Fixes: First deny-list approach (2010), then partial allow-list approach (2022) - Struts uses OGNL. -> CVEs: CVE-2017-5638 (Equifax breach), and others -> CVE Fixes: deny-list approach (-2017-) If there are any for Java, can they be used with Spring Boot (Spring Framework)? Maybe there are some for in another programming language? [0] https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/bind/WebDataBinder.html https://docs.spring.io/spring-framework/docs/current/javadoc... > Special DataBinder for data binding from web request parameters to JavaBean objects.
- alipitch 4y ago
  Also to understand the problem correctly, what is the class of weakness of the two CVEs (CVE-2022-22965, CVE-2010-1622)? The following look like good candidates. - CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes <https://cwe.mitre.org/data/definitions/915.html https://cwe.mitre.org/data/definitions/915.html> (Ruby on Rails Mass assignment bug) - CWE-502: Deserialization of Untrusted Data <https://cwe.mitre.org/data/definitions/502.html https://cwe.mitre.org/data/definitions/502.html> - CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') <https://cwe.mitre.org/data/definitions/470.html https://cwe.mitre.org/data/definitions/470.html> I think the one assigned (CWE-20:) is not a good approach to dealing with the "class" of weaknesses. - CWE-20: Improper Input Validation <https://cwe.mitre.org/data/definitions/20.html https://cwe.mitre.org/data/definitions/20.html> As long as you see this as a "CWE-20: Improper Input Validation" class problem, it seems like you try to fix this with a deny-list approach or a partial allow-list approach that needs additional fixing some time in the future.

157 points by groundshark 4y ago

mbfg 4y ago

Fortunately very few companies of any size use jdk9+

EdwardDiego 4y ago
Unfortunately you're wrong. While some companies haven't yet made the leap from 8 to 11, most have. You'll find that Java 8 support is being deprecated if not outright removed across the JVM ecosystem.
- krzyk 4y ago
  I would say fortunately. Oracle premier support for JDK 8 ends today.
- mbfg 4y ago
  Can you point me to surveys to back up this claim? I interview lots of people from lots of companies, no one is using anything above java 8. Sure this evidence is anecdotal, but i've probably got evidence from around 150 companies.
  - EdwardDiego 4y ago
    Nothing I can share, sorry.

groundshark 4y ago

Possible 0-day RCE impacting Spring applications.

EdwardDiego 4y ago
Possible...

olliej 4y ago

Looks like another "I'm in a 'safe' language, so can do unsafe things" crossed with the standard object deserialization error of default allowing any class to be instantiated. The temporary fix that they list seems to imply that the current APIs don't allow specifying a finite list of allowed classes?

dboreham 4y ago
Any kind of writable reflection facility, and any kind of eval() should be added to the set of "unsafe" features.
- hsbauauvhabzb 4y ago
  At some point, mvc frameworks have to do some magic to dynamically load classes. This should be done at runtime, but can’t imagine it’s an easy problem to solve.
  - richbell 4y ago
    Frameworks like Quarkus and Micronaut do this at compile time. They dynamically load things and record it, then insert the resulting bytecode statically in the build artifact. I believe the core motivator is performance, but it has the added benefit of eliminating most of the runtime magic that leads to vulnerabilities like this.
  - dboreham 4y ago
    Not my field, but how can this be so? We had MVC in 1990 written in C or C++.
    - olliej 4y ago
      In principle I think you could do something like this with COM, but I’m unaware of any such framework
  - olliej 4y ago
    No they don’t, MVC has existed in C++ for decades. The problem is specific to reflection based MVC frameworks (objc has similar issues). The solution is to explicitly specify every class that can be instantiated at compile time. Similar to how modern deserialization frameworks work. No code should be written that allows content from the network to explicitly specify arbitrary code to load and execute. E.g having a packet say <view class=“MyView”> and feeding the string “MyView” into some classloader, or dlsym, or whatever is asking for trouble. Feeding it into switch (view.class) { case “MyView”: return new MyView() … } Results in a much less powerful primitive

scanr 4y ago

“This vulnerability allows an unauthenticated attacker to execute arbitrary code on the target system.”. Interesting that the CVE has been around for so long.

skered 4y ago

JDK9+? Not just 9.

rlevy 4y ago
Yes

invokestatic 4y ago

I am still deeply skeptical that this exploit really exists, or if it does, it is extremely exaggerated. I can’t really articulate the reasons why. Part of it is the fact that a lot of the people reporting on it self-admit that they are unfamiliar with Java and Spring. One “PoC” repo I’ve seen is just simple API misuse. API misuse is a CVE in the application that does the misusing, NOT the library that is misused (in this case spring). Something else is that very soon after there was a /hint/ of a log4j exploit, we saw rapid and evolving exploitation in the wild. We have nothing like that happening now, since this news first broke, what, 12 hours ago? Then there’s also the suspicion where I feel the LunaSec people, one of the first groups to report on this, are desperately trying to re-catch the fire they caught when they first reported log4j. I’m sure that was amazing for marketing their company. Problem is, I think reporting on this before there is really indication of a real issue reduces the credibility of them as competent security researchers. Of course, I may come back to eat my words.

freeqaz 4y ago
LunaSec founder here. I can understand the suspicion. It's the right mindset to have when looking at CVEs, in general, because 99% of them are overblown. The first title I wrote for the blog post was "There is no vuln" but I was wrong. Only after I spent a few hours digging did my gut change my mind. In this case I wrote the post to discuss 2 different vulns. One was a confirmed RCE with a CVE and the other was a WIP with only sketchy Twitter screenshots to go on. That alone was confusing many people and was the reason many people were posting about finding an "RCE POC" without realizing they were talking about the wrong vuln. That was the primary reason that we (LunaSec) wrote the original post -- to help people understand that there were 2 vulns and that they needed to be careful to confirm which they were discussing. There was too much unwarranted hype, too much confusion, and too little "real" information to prove/disprove if an exploit was possible. That said, at some point as researchers, we have to trust our gut about potential impact and exploitability without full knowledge of the vuln. With Log4Shell, when we wrote that post, we hadn't personally proven that the JNDI vulnerability could be exploited. It just felt like a matter of time before it would be figured out by somebody much smarter that us. And with this exploit and the people discussing it, it felt like there was likely something there (which has turned out to be true, retroactively). So that's the line, as researchers, that we have to balance by attempting to provide an "early warning" for companies/devs while also not just sitting for days with the vulnerable code (in this case Spring) to prove out an exploit until a bunch of blackhats already move on to mass exploitation. Anyway, at this point, people that I trust a lot have come forward to say that they were able to verify the exploit with a POC themselves. Specifically, @pwntester has tweeted about this[0][1] confirming that he's been able to get an exploit. He's a very good Java dev that is much, much faster than myself or anybody else on my team. -------- In this case, I noticed some people talking about it on Twitter and tried to put together info to help people "prove out" a POC with a "basic vulnerable app". Then I went to bed and looked at this again. That's when I realized that this was very confusing because there were multiple vulns being conflated in different libs. And then the Spring devs said that this wasn't an issue, but it very much still felt like there was the possibility for an exploit still. It turned out to be "Class Loader Manipulation" instead of "Deserialization injection" but the activity relating to this on Twitter was real. I sat with my engineers for several hours just poking at getting a POC working and we're very confident that, with a little more time, we'll be able to turn this into a POC like the Struts one. We're just not Java guys so it's slow. Getting a debugger takes time, understanding Spring takes time, etc. There are much more competent devs and researchers out there than us -- we're just trying to reduce the uncertainty and misinformation in a way that helps companies patch faster. Communicating clearly about hard technical subjects while also writing POCs on-the-fly is difficult, and I apologize if what I wrote came across as more "corporate shill" than "security researcher trying to reduce entropy". That's on me! 0: https://twitter.com/pwntester/status/1509240072301912074 https://twitter.com/pwntester/status/1509240072301912074 1: https://twitter.com/pwntester/status/1509248853614239747 https://twitter.com/pwntester/status/1509248853614239747 EDIT: Clarified some text

freeqaz 4y ago

(Author that named "Log4Shell" here) FYI, this is confusing because there are 2 different RCEs that have been published within the last 24 hours. One has a CVE and the other doesn't. OP's post by Praetorian is discussing the RCE dubbed "Spring4Shell". It's the RCE without a CVE yet, hence the name, and it affects Spring Core. It's likely fairly widespread/severe, but the "mitigating details" are still unknown. That said, it's very similar to the Apache Struts vuln that popped EquiFax a few years ago. (a Class Loader Manipulation exploit) So there is already some tooling available to weaponize it. The other RCE affects Spring Cloud Function and has been given CVE-2022-22963. We wrote a post[0] with info on both CVEs that references this Praetorian post under the "Remediation" section. We also added more information about the exploit scenarios to help push the ball forward for determining how widely exploitable this is going to be. (There is a 3rd possible one too, but it's still unconfirmed.) Basically, the authors of Spring Core tweeted[1] that there wasn't a vuln and that has added to the chaos of this. There is a vuln here. It's not as bad as Log4Shell, but it's still bad and likely widely exploitable given how popular Spring Core is and how some Java devs[2] have confirmed that the exploitable configuration is a "common pattern" in real-world usage. With the vuln there are more steps required for exploitation. That means kids on Minecraft won't be griefing each other with it, but that won't stop the blackhats from weaponizing this quickly. After all, this is a very similar attack to previous ones in Struts[3]. So if you're using Spring Core or Spring Cloud Function, it's a good idea to stay up-to-date on this stuff because it's moving pretty quick. If you already looked earlier this morning, a lot has changed (like this Praetorian post). It'll be a fun weekend for security teams everywhere! 0: https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/ https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/ 1: https://twitter.com/hacksilon/status/1509117953064812547 https://twitter.com/hacksilon/status/1509117953064812547 2: https://twitter.com/pwntester/status/1509298152691671046 https://twitter.com/pwntester/status/1509298152691671046 3: https://www.exploit-db.com/exploits/33142 https://www.exploit-db.com/exploits/33142

smrtinsert 4y ago
I have never seen that class SerializationUtils used in the wild. Now if it was in Jackson...

WatchDog 4y ago

There is a lot of bad information out there about this issue. What I have gathered so far, is that this is actually a real problem, but it may not affect most configurations. This[0] seems to be the original vulnerability analysis, and this is the example vulnerable app[1]. The main issue seems to be, that since java 9, WebDataBinder can be abused to access the classloader via the "class.module.classloader", you might think that "class.classloader" would work, but it's explicitly filtered out[2], it seems they need to add some filtering for module, as well. The proof of concept, then access the "AccessLogValve" class via "class.classLoader.resources.context.parent.pipeline.first", which is only accessible if the application is running using a "WeappClassLoaderBase", it then configures the logger, to output an arbitrary JSP file to the webapp root directory, which can then be used to get a shell. It looks like this issue is only exploitable if your app is deployed as a war file. [0]: https://github.com/TheGejr/SpringShell/blob/master/Vulnerability%20Analysis%20%5BCHINESE%5D.pdf https://github.com/TheGejr/SpringShell/blob/master/Vulnerabi... [1]: https://github.com/fengguangbin/spring-rce-war https://github.com/fengguangbin/spring-rce-war [2]: https://github.com/spring-projects/spring-framework/blob/main/spring-beans/src/main/java/org/springframework/beans/CachedIntrospectionResults.java#L291 https://github.com/spring-projects/spring-framework/blob/mai...

awirth 4y ago
If you can access the classloader that's pretty bad, it's likely people will find other gadgets. It's insane to me though that class.* isn't completely disallowed. What is the legitimate use case for deserializing allowing web requests to call setters in the reflection API? Also, agree it is impressive to me how much bad information I've seen.
- loginatnine 4y ago
  Yea it didn't help that this was posted a bit after 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... and that the original article mentioned a commit on the class `SerializationUtils` which in the end has no connection to this. I believe accessing the `class` object here is a mistake. You can see my analysis here where I trace the POC https://news.ycombinator.com/item?id=30862953 https://news.ycombinator.com/item?id=30862953 but like you said, there are other problematic code paths for sure with this.

tauwauwau 4y ago

Not sure why it's tagged JDK9+, but 'class' attribute is accessible on org.springframework.beans.BeanWrapperImpl.getLocalPropertyHandler() in JDK 8 also. It probably doesn't matter which JDK is being used, as long as this spring-beans dependency is used. Whether logging JSP exploit in JDK 8 or lower can be used is another question. However, since 'class' is accessible via request parameter, it's already bad and there will probably be some ways to exploiting it. It doesn't matter whether the request is GET or POST, as long as mapped controller method uses a non-primitive request object, 'class' can be accessed. 'class.module' attribute is accessible from Java 9 and above, I tested on Java 11 and can access 'class.module'. Sample code that I used to test this with JDK 8 is below. I just tested whether 'class' attribute can be accessed via request parameter. curl -X POST localhost:8080/test?class.modifiers=Hello package com.test; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.web.bind.annotation.PostMapping; import org.springframework.web.bind.annotation.RestController; @SpringBootApplication public class Spring4ShellTestApplication { public static void main(String[] args) { SpringApplication.run(Spring4ShellTestApplication.class, args); } } @RestController class TestController { @PostMapping("/test") public String test(TestOuterRequest request) { String message = "Inner request is null"; if (request.getInnerRequest() != null) { message = "your message was: " + request.getInnerRequest().getMessage(); } System.out.println(message); return message; } } class TestOuterRequest { private TestInnerRequest innerRequest; public TestInnerRequest getInnerRequest() { return innerRequest; } public void setInnerRequest(TestInnerRequest innerRequest) { this.innerRequest = innerRequest; } } class TestInnerRequest { private String message; public String getMessage() { return message; } public void setMessage(String message) { this.message = message; } } Finally here are the attributes that're exposed on 'class' as accessible properties in JDK 8 (JDK9+ adds 'module' on top of all these) annotatedInterfaces annotatedSuperclass annotation annotations anonymousClass array canonicalName class classes componentType constructors declaredAnnotations declaredClasses declaredConstructors declaredFields declaredMethods declaringClass enclosingClass enclosingConstructor enclosingMethod enum enumConstants fields genericInterfaces genericSuperclass interface interfaces localClass memberClass methods modifiers name package primitive signers simpleName superclass synthetic typeName typeParameters

toyg 4y ago

Title should be fixed to say 9+ (as in the original source). I initially discounted the issue because v9 was a somewhat-experimental release that very few people ever ran in production; but later versions were mainstream, and if they are all vulnerable, then this is a major problem.

Copenjin 4y ago

Official announcement, a better remediation is proposed: https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement https://spring.io/blog/2022/03/31/spring-framework-rce-early... A new spring release should come out today.

hrpnk 4y ago

https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement https://spring.io/blog/2022/03/31/spring-framework-rce-early... "[11:59 BST] Spring Framework versions 5.3.18 and 5.2.20, which address the vulnerability, are now available on Maven Central. The release process for Spring Boot is in progress, but applications can already upgrade their Spring Framework version independently in order to be protected."

trollied 4y ago

Spring have blogged about it. Releases are on the way: https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement https://spring.io/blog/2022/03/31/spring-framework-rce-early...

alipitch 4y ago

Are there any data binding libraries (deserialization, marshaling, pickling libraries) that do not have the class of weaknesses as the two CVEs (CVE-2022-22965, CVE-2010-1622)? My understanding is as follows. - Spring uses WebDataBinder [0]. -> CVEs: CVE-2022-22965 (Spring4Shell), CVE-2010-1622 -> CVE Fixes: First deny-list approach (2010), then partial allow-list approach (2022) - Struts uses OGNL. -> CVEs: CVE-2017-5638 (Equifax breach), and others -> CVE Fixes: deny-list approach (-2017-) If there are any for Java, can they be used with Spring Boot (Spring Framework)? Maybe there are some for in another programming language? [0] https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/bind/WebDataBinder.html https://docs.spring.io/spring-framework/docs/current/javadoc... > Special DataBinder for data binding from web request parameters to JavaBean objects.

alipitch 4y ago
Also to understand the problem correctly, what is the class of weakness of the two CVEs (CVE-2022-22965, CVE-2010-1622)? The following look like good candidates. - CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes <https://cwe.mitre.org/data/definitions/915.html https://cwe.mitre.org/data/definitions/915.html> (Ruby on Rails Mass assignment bug) - CWE-502: Deserialization of Untrusted Data <https://cwe.mitre.org/data/definitions/502.html https://cwe.mitre.org/data/definitions/502.html> - CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') <https://cwe.mitre.org/data/definitions/470.html https://cwe.mitre.org/data/definitions/470.html> I think the one assigned (CWE-20:) is not a good approach to dealing with the "class" of weaknesses. - CWE-20: Improper Input Validation <https://cwe.mitre.org/data/definitions/20.html https://cwe.mitre.org/data/definitions/20.html> As long as you see this as a "CWE-20: Improper Input Validation" class problem, it seems like you try to fix this with a deny-list approach or a partial allow-list approach that needs additional fixing some time in the future.