Live data from Hacker News

Spring Core on JDK9 is vulnerable to remote code execution

praetorian.com

31–40 of 73 posts

Re: Spring Core on JDK9 is vulnerable to remote code execution

#31
post #9

Earlier quoted context omitted.

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…

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/ /tomcatwar.jsp and that is s…

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

Re: Spring Core on JDK9 is vulnerable to remote code execution

#32
post #9

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…

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…

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

Re: Spring Core on JDK9 is vulnerable to remote code execution

#33

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 migh…

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.

Re: Spring Core on JDK9 is vulnerable to remote code execution

#34
post #11
post #10

Earlier quoted context omitted.

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 ha…

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

Re: Spring Core on JDK9 is vulnerable to remote code execution

#35

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…

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.

Re: Spring Core on JDK9 is vulnerable to remote code execution

#36
post #10

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…

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

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.

Re: Spring Core on JDK9 is vulnerable to remote code execution

#37

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…

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.

Re: Spring Core on JDK9 is vulnerable to remote code execution

#38
post #15

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.

Re: Spring Core on JDK9 is vulnerable to remote code execution

#39
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.

Re: Spring Core on JDK9 is vulnerable to remote code execution

#40

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 migh…

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.

Post reply on HN