4 ms·

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

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/Vulnerability%20Analysis%20%5BCHINESE%5D.pdf https://github.com/TheGejr/SpringShell/blob/master/Vulnerabi... [1]: https://github.com/fengguangbin/spring-rce-war https://github.com/fengguangbin/spring-rce-war [2]: https://github.com/spring-projects/spring-framework/blob/main/spring-beans/src/main/java/org/springframework/beans/CachedIntrospectionResults.java#L291 https://github.com/spring-projects/spring-framework/blob/mai...

deleted 5y ago
[deleted]
awirth 5y ago
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.
- loginatnine 5y ago
  Yea it didn't help that this was posted a bit after https://spring.io/blog/2022/03/29/cve-report-published-for-spring-cloud-function 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 https://news.ycombinator.com/item?id=30862953 but like you said, there are other problematic code paths for sure with this.
znep 5y ago
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.html#getModule-- 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.
jillesvangurp 5y ago
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.
- KronisLV 5y ago
  > 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.
  - xxs 5y ago
    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.
    - KronisLV 5y ago
      > 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.
twic 5y ago
> 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!
- bcrosby95 5y ago
  The default config for tomcat is to explode the WAR, even in the most recent version.

deleted 5y ago

[deleted]

awirth 5y ago

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.

loginatnine 5y ago
Yea it didn't help that this was posted a bit after https://spring.io/blog/2022/03/29/cve-report-published-for-spring-cloud-function 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 https://news.ycombinator.com/item?id=30862953 but like you said, there are other problematic code paths for sure with this.

znep 5y ago

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.html#getModule-- 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.

jillesvangurp 5y ago

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.

KronisLV 5y ago
> 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.
- xxs 5y ago
  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.
  - KronisLV 5y ago
    > 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.

twic 5y ago

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

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