Spring Core on JDK9 is vulnerable to remote code execution

Post by bcrosby95 » Thu, Mar 31, 2022, 3:44 PM UTC

twic wrote: post #45

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…

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

Post by mbfg » Thu, Mar 31, 2022, 7:00 PM UTC

EdwardDiego wrote: post #38

mbfg wrote: 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.

Post by tru3_power » Fri, Apr 01, 2022, 1:52 AM UTC

sjones671 wrote: post #29

freeqaz wrote: 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…

Post by bzzzt » Fri, Apr 01, 2022, 9:20 AM UTC

xxs wrote: post #53

KronisLV wrote: post #50

Earlier quoted context omitted.

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

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…

Post by olliej » Fri, Apr 01, 2022, 11:54 PM UTC

hsbauauvhabzb wrote: post #19

dboreham wrote: post #16

Earlier quoted context omitted.

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.

    switch (view.class) {
       case “MyView”: return new MyView() … }