Spring Remote Code Execution Vulnerability
talktotheduck.dev
talktotheduck.dev
The problem in spring is the WebDataBinder able to manipulate objects through the class loader. This affects Java 9+ because the previous mitigation of the class loader access is insufficient with the introduction of Java modules. The exploit utilizes a path from the current class to the module to the classloader, where previous mitigations removed access to the classloader from the class directly AFAICT.
The reasoning that this isn't THAT bad: this only affects the WebDataBinder marshalling which happens for default web form POST content types. Utilizing the commonly used @RequestBody annotation (for proper marshalling from JSON/XML) is not impacted. Utilizing the @RequestBody annotation causes marshalling to use the HTTPMessageConverter which is not affected.
On top of this the deployment matters. Different servlet containers use different class loaders/expose different class loaders. Currently, I have not seen an exploit for this in embedded tomcat (my debugging of this code path will not inject in code, presumably because the URLClassLoader is different than the class loader provided in the standalone tomcat deployment). I have not investigated whether this is because of security checks or some other functionality.
So very specifically: 1. You have to be using the WebDataBinder (not default for JSON serialized endpoints) 2. The servlet container matters (embedded Tomcat) 3. The endpoints have to be known or spidered
Overall, I believe this vulnerability has been quite overhyped right now.
Spring samples are vulnerable and all you need is one vulnerable endpoint which you can detect. From then on the vulnerability is generic.
The tomcat requirement is a limitation of the current exploit. If you can set arbitrary global flags in the container you can do a lot of things that will impact other deployments too.
At my company we are doing our due diligence as a java shop and in all the code we have been scouring we have not found anything exploitable.
The configuration in use here is not the most common for modern development practices and spring. This only affects non JSON APIs using the WebDataBinder.
The do not believe the point about tomcat is correct. Testing the most simple payload that directly interacts with the class loader is not triggering because the class loader in non-standalone tomcat does not allow accessing these fields.
In fact tomcat is patching this as well to prevent this from happening. This configuration of Tomcat is part of the problem. I'm open to seeing proof otherwise, but so far there has been nothing published that shows that other servlet configurations are exploitable.
Since a typical Spring application has a lot of dependencies I'm sure some 3rd party library somewhere could be susceptible. Embedded Tomcat which is pretty common might have an exploit we can't imagine at this moment.
I have stopped my research for now because of the limited scope so I am not spending more time debugging the exact differences in the class loaders in use here, because the configuration required for the exploit to work makes 99.9% of my use cases just plain not work as it is default web form marshalling which we do not do.
We of course are updating: You should update too, it's good hygiene, but the fact of the matter is this is no where close to the same blast radius for the reason that it requires such a bad configuration to start with and doesn't affect non-public services like log4shell had the possibility to do.