Live data from Hacker News

Spring Core on JDK9 is vulnerable to remote code execution

praetorian.com

41–50 of 73 posts

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

#41

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

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

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

#42
post #13
post #12

Earlier quoted context omitted.

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?

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

#43
post #13

Earlier quoted context omitted.

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

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

#44

Earlier quoted context omitted.

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

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

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.

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

#45

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…

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

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

#46
post #43

Earlier quoted context omitted.

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.

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

#47

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…

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

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

#48
post #36
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".

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.

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

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

I would say fortunately.

Oracle premier support for JDK 8 ends today.

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

#50
post #44

Earlier quoted context omitted.

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

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.

Post reply on HN