Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Spring Core on JDK9 is vulnerable to remote code execution

praetorian.com

Post reply on HN
Print view View original

11–20 of 73 posts

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

#11

Post by freeqaz »

vips7L wrote: post #10
invokestatic wrote: post #7

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

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)

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

#12

Post by EE84M3i »

freeqaz wrote: post #11
vips7L wrote: 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 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.

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

#13

Post by freeqaz »

EE84M3i wrote: post #12
freeqaz wrote: post #11

Earlier quoted context omitted.

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

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

#14

Post by alexis2b »

invokestatic wrote: post #7

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

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

#16

Post by dboreham »

olliej wrote: post #4

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.

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

#17

Post by WatchDog »

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

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

#18

Post by hsbauauvhabzb »

freeqaz wrote: post #11
vips7L wrote: 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…

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.

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

#19

Post by hsbauauvhabzb »

dboreham wrote: post #16
olliej wrote: post #4

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.

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

#20

Post by [deleted] »

WatchDog wrote: post #17

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…

[deleted]
Post reply on HN