3 ms·

There are spring samples that are vulnerable. There are bound to be vulnerable applications. However to equate it with log4shell is clickbait. This is no where

There are spring samples that are vulnerable. There are bound to be vulnerable applications. However to equate it with log4shell is clickbait. This is no where near as bad because of the preconditions required. 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.

invalidname 5y ago
I agree, it isn't as bad as Log4J if only for the fact that it's JDK 9+ specific. A lot of our deployments are still on Java 8. So even if they are vulnerable we're sort of protected by being slow. 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.
- 0x500x79 5y ago
  This is true, but seems unlikely from my analysis this far. The class loader behavior is vastly different and attempting to access classes is failing to write fields (getting the default: Field is not accessible when attempting to write bean) on all payloads that I have been trying. 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.

invalidname 5y ago

I agree, it isn't as bad as Log4J if only for the fact that it's JDK 9+ specific. A lot of our deployments are still on Java 8. So even if they are vulnerable we're sort of protected by being slow. 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.

0x500x79 5y ago
This is true, but seems unlikely from my analysis this far. The class loader behavior is vastly different and attempting to access classes is failing to write fields (getting the default: Field is not accessible when attempting to write bean) on all payloads that I have been trying. 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.