Spring Core on JDK9 is vulnerable to remote code execution | Hacker News Reader

Spring Core on JDK9 is vulnerable to remote code execution

praetorian.com

157 pointsgroundshark70 comments

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/Vulnerabi...

[1]: https://github.com/fengguangbin/spring-rce-war

[2]: https://github.com/spring-projects/spring-framework/blob/mai...

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.

Yea it didn't help that this was posted a bit after 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 but like you said, there are other problematic code paths for sure with this.

Ahh, your comment is the first one that made it clear why this is only in 9 and later, because it was actually "introduced" by the introduction of modules in Java 9. That added https://docs.oracle.com/javase/9/docs/api/java/lang/Class.ht... to java.lang.Class.

It looks like the Spring code, when written, did properly filter out existing unsafe methods in java.lang.Class deliberately. Obviously not in a defensive enough way to avoid this, but adding methods to java.lang.Class is a very rare event.

Right, war files are still a thing for people stuck on older architectures involving things like tomcat or jboss. The venn diagram of doing that with current JDKs and modern spring would be pretty narrow. Most people would just use spring boot, which runs as a simple server that starts via a main function. Usually jetty or tomcat in embedded mode. If you really wanted to, I guess you could pack it up as a war file and deploy that. But I've never seen anyone do that with Spring Boot. The last time I worked with tomcat was about 10 years ago before either Spring Boot or Java 8 were a thing.

Nasty issue though and they should close it off.

> If you really wanted to, I guess you could pack it up as a war file and deploy that. But I've never seen anyone do that with Spring Boot.

I have actually seen this done. It was extremely underwhelming and provided no tangible benefits versus just having an executable .jar file instead. The filesize difference was negligible and being able to update Tomcat versions separately wasn't all that useful. In the end, the project was migrated over to running as a .jar instead.

Then again, i've also seen projects where Jetty is used locally and .war with Tomcat is used when deployed, which was an inconsistent mess.

Overall, Tomcat is pretty cool but the ease of use with Spring Boot running Tomcat or anything else in embedded mode is really nice.

The main benefit is updating the webapps w/o restarting the server, itself. Spring, itself, is a rather slow due to on the fly bean resolution/binding/etc. though, so the benefits are not that pronounced.

> The main benefit is updating the webapps w/o restarting the server, itself.

I've never had this work properly in the long term, to be honest. Restarts with the Jenkins plugin would randomly freeze and fail or there would be memory leaks after too many restarts, or weird errors about it not being possible to properly clear up the resources from previously exploded/extracted .war archives.

Though i might have just been unlucky, who knows.

There are many things that must go right. Threads being the primary one - don't start threads, pretty much anything that can start threads (outside the webapp) have to guard for the CCL and the thread group at the very least.

The entire app must have a clear start/stop lifecycle correctly implemented. Static registrations in non-webapp services must be removed, and/or those services must use weak references.

The list is quite long. (Source - I have done my fair share of middleware and know tomcat source quite well)

While this is possible, it takes ages for an application to gracefully shutdown so any time you save not having to start up a new server is lost. And then you still have classloader, memory and thread leaks since you can't really prove they are absent unless you have 100% test coverage + load testing on every possible code path.

Modern Java webservers (even 'enterprise' containers like JBoss etc) start up so quickly now there's not much to gain by not restarting them.

>And then you still have classloader, memory and thread leaks since you can't really prove they are absent unless you have 100% test coverage + load testing on every possible code path.

Those are trivially proven and diagnosed with memory dumps or even "jmap -histo"(incl. where the leak started). Zero test coverage for that needed. Some bugs were even in JDK where it'd start a new thread in a threadpool and copy all the CCL/Threadgroup/ACL and any inheritable thread local.

> output an arbitrary JSP file

So i appreciate that this is only an example of a gadget, and there are others that could be invoked in the same way, but ...

> to the webapp root directory

This is only possible if the application is running from an exploded WAR. That can happen if the developer deploys an exploded WAR - normal in development, extremely strange in production - or if the application server explodes the WAR to run it. I know it used to be standard for application servers to do that, but my understanding was that they stopped doing this 5 - 10 years ago, and now run applications directly from the WAR file. That said, i am certainly not intimately familiar with all extant application servers, or what versions are in use - perhaps there are plenty of deployments that still do this.

I always argued for deploying the app as one user, then executing it as another, which didn't have write access to the deployment, specifically to avoid this class of problem, but nobody ever bothers to do that!

The default config for tomcat is to explode the WAR, even in the most recent version.

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.

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

1: https://twitter.com/pwntester/status/1509248853614239747

EDIT: Clarified some text

The exploit PoC that is doing the rounds works on full tomcat, not embedded tomcat, so if your example vulnerable application is using embedded tomcat that exploit won't work on it without being tweaked.

I've looked at it today as well, for most of the day. Embedded tomcat doesn't have a webapps directory, whereas the full version of tomcat does, so the PoC writes the webshell to webapps/<APP>/tomcatwar.jsp and that is served up then.

I'm on OSX and I found the temp directory that is created for the embedded tomcat at runtime but there's nothing deployed there, so I can't figure out where to write the webshell to or if it is even possible. I looked at the process with lsof and just followed the trail to find the directory but it's not working.

Anyway, embedded tomcat IS vulnerable, just not sure if it is exploitable.

To check if it is vulnerable you can do run the following curl command: curl "http://localhost:8080/?class.module.classLoader.URLs%5B0%5D=..."

If this returns status:400 then it is vulnerable, if not then it is not. If you have an app deployed to a different context path (so /my-webapp) then you'd need to run: curl "http://localhost:8080/my-webapp?class.module.classLoader.URL..."

I don't think it is common to use @RequestMapping in java and take in a POJO as a parameter to the request, but that is needed in order to be vulnerable to this.

I'm sure there's other gadgets that can be used to exploit this, the example we saw was using tomcat to write a webshell.

> I don't think it is common to use @RequestMapping in java and take in a POJO as a parameter to the request, but that is needed in order to be vulnerable to this.

Wouldn't any method annotation like @PostMapping be vulnerable? The vulnerability is in how Spring loads the beans, so in theory any endpoint that loads a bean would trigger the exploit regardless of method.

I just came to the same conclusion after some debugging. On embedded tomcat there is no access to resources and thus the popular PoC floating around doesn’t work. I left off for the night exploring getters/setters on the URL object returned on the URLs[0] call. On Java 11 there were some interesting getters/setters I want to explore. Let me know if you find a working PoC. Fun stuff!

I always find in confomfortable when using "my engineers".

I'm skeptical as well because everyone is saying they've reproduced it, but there's no CVE and none of them want to post the source code to reproduce it. It's all "use this closed source docker image" or "it was in this now deleted github" or "it was in this now deleted twitter leak".

Nobody wants to hand a bunch of blackhats a working exploit without there being a patch available. But yeah, at some point you have to accept that the blackhats have it and it's "more ethical" to just start handing out the exploit POC so that companies can start testing their ability to detect + remediate the issue.

It's the whole "responsible disclosure" dance. Finding a 0-day is exciting as a researcher, but you have to keep your mouth shut while a fix gets built and tested. (Google's Project Zero gives a 90 day grace period, for example)

The post says "there is a public proof-of-concept available." If that's true, just link to it. The cat's already out of the bag.

Thanks for pointing that out -- I didn't realize we missed adding the link! It's in a repo on GitHub, and we were banging on it to verify the exploit prerequisites.

I'll go do that as soon as I sit down again.

I still can't find it.. Got the link to the repo?

I'll ask my engineers to post the one he wrote. He did put more details into the article, so go check that. Here is a repo with a POC though: https://github.com/TheGejr/SpringShell

That’s not really a POC though. That’s not a Spring Application I can run and reproduce on. That’s just a py script.

The PDF in the repo contains a simple Java sample that should be straightforward to build and run.

Yeah it doesn't work with a default Spring MVC project from start.spring.io on Jdk 18. It's hardly a proof of concept without any configuration details of the spring project. Security researchers need to do better than this.

Check the post again. We made a repo with a full end to end vulnerable app and POC

How is handing out a poc 0day ethical when it’s leaked but difficult to find? I’d rather see it censored until at least a patch drops + grace period.

I guess it’s a case by case basis, adding app-specific waf rules will be handy, but that only matters if exploitation patterns are unique per applications, otherwise generic rules could be published.

The whole basis of this claim was a commit in a merged PR yeah?

No. There was a credible report, but one of the blogs (Cyber Kendra) linked to a commit that mentioned RCE off hand and said "it looks like they're cleaning up".

https://spring.io/blog/2022/03/31/spring-framework-rce-early...

> but there's no CVE

The notion of a National Vulnerability Database is noble, but creating a CVE is an incredibly slow moving and bureaucratic process. In situations like this, or Log4Shell, information evolves rapidly and is often outdated by the time it makes it to NVD. Log4Shell specifically was a disaster, where the original advisory text contained incorrect information that was corrected relatively quickly by Apache but did not update in NVD for weeks. This actively hurt the remediation efforts as people treated the description in NVD as the authoritative source for information and ignored evidence to the contrary.

Lack of an assigned CVE is a really bad reason to discount anything, it's a bureucratic process with various tangential limitations, rules and delays.

CVEs are frequently created for minor issues, like the recent Jackson bug that has very specific (and not frequent) case.

According to this article [0] there are already signs of exploitation in-the-wild.

0: https://www.bleepingcomputer.com/news/security/new-spring-ja...

I'm dubious because none of their sources saying so have names.

Makes me wonder if their sources are trying to inspire fear to drum up business.

I've spent most of my day on this and can confirm there is serious potential to this. It's not a log4shell but it's serious.

You're potentially vulnerable if you use POJOs as request parameters[0] with Spring MVC and Java 9+. To support complex POJOs (like a POJO in a POJO), Spring uses the `.` separator. Therefore, you can have a request GET /somePath?innerPojo.field=foo that will get mapped properly [1].

Now, in [2], the `getCachedIntrospectionResults()` result has a `class` parameter that I believe should not be exposed. In this object, there's a bunch of parameters that can be set, that's where the problem is. In the POC seen across the web today, it was modifying the `AccessLogValve` of Tomcat. The exploit mentioned in [3] relies on passing a parameter like this :

GET /somePath?class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp

This will access the `class` object and uses the `getModule` method of the `Class` object to get the `Module` class. Now, this class has the `ClassLoader` exposed via a getter BUT it's exposed as opposed to the `Class` class[4]! In the POC, it's an instance of `WebAppClassLoaderBase` (when using Tomcat, under some circumstances). This class has a `getResources` method that is accessed here, along with `getContext`, `getParent`, etc. all the way up to the last delimiter which invoke the `setSuffix` method of the `AccessLogValve` instance [5]. Rinse and repeat this to set the tone for the JSP vulnerability and you have a RCE.

Now, this needs some specific preconditions. However, there are probably hundred of other mutable objects accessible this way that could lead to pretty nasty bugs, vulnerability of information disclosures.

Finally, I can confirm that the workaround with `@InitBinder` mentioned in [6] works.

EDIT : Looks like a regression from CVE-2010-1622 that was fixed in [7].

[0] https://docs.spring.io/spring-framework/docs/3.2.x/spring-fr...

[1] https://gist.github.com/jebeaudet/127e6fb0b59e06c0642d2f362e...

[2] https://github.com/spring-projects/spring-framework/blob/mai...

[3] https://www.cyberkendra.com/2022/03/spring4shell-details-and...

[4] https://github.com/spring-projects/spring-framework/blob/mai...

[5] https://github.com/Oreste-Luci/apache-tomcat-8.0.26-src/blob...

[6] https://www.cyberkendra.com/2022/03/springshell-rce-0-day-vu...

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

Are you referring to existence of the exploit they say they sent to the Spring team?

I think in general it's a bad social standard that people get asked for proof by exploit about disclosed vulnerabilities. At most it should be a tool to convince the vendor if they're not competent enough to see the exploitability right away. In many cases developing it is more work than finding the hole, you're just doing work toward faster weaponisation by bad guys, and distracts from vulnerability research.

https://spring.io/blog/2022/03/31/spring-framework-rce-early...

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... > Special DataBinder for data binding from web request parameters to JavaBean objects.

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> (Ruby on Rails Mass assignment bug)

- CWE-502: Deserialization of Untrusted Data <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>

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>

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.

Official announcement, a better remediation is proposed: https://spring.io/blog/2022/03/31/spring-framework-rce-early...

A new spring release should come out today.

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.

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

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

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

1: https://twitter.com/hacksilon/status/1509117953064812547

2: https://twitter.com/pwntester/status/1509298152691671046

3: https://www.exploit-db.com/exploits/33142

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

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?

Any kind of writable reflection facility, and any kind of eval() should be added to the set of "unsafe" features.

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.

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.

Not my field, but how can this be so? We had MVC in 1990 written in C or C++.

In principle I think you could do something like this with COM, but I’m unaware of any such framework

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

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

JDK9+ is important because Spring already prevents access to `class.classloader`, but it can be worked around thanks to modules (i.e. `class.module.classloader` works).

Yes but there may be some other Gadget vulnerabilities in all those fields too. Also, you might be able to make an app OOM by setting big string values somewhere in there.

It boggles my mind why this field is accessible at all and wasn't blocked in CVE-2010-1622.

You can make an app OOM by setting big string values anywhere. You gotta handle that at a higher level and reject requests larger than a certain size, which there is already a default for.

I spent a good amount of time trying to find some gadgets on jdk8 today no dice besides some DoS

JDK9+? Not just 9.

Yes

“This vulnerability allows an unauthenticated attacker to execute arbitrary code on the target system.”.

Interesting that the CVE has been around for so long.

Possible 0-day RCE impacting Spring applications.

Possible...

Fortunately very few companies of any size use jdk9+

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.

I would say fortunately.

Oracle premier support for JDK 8 ends today.

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.

Nothing I can share, sorry.

Reply on news.ycombinator.com