51–60 of 73 posts
Earlier quoted context omitted.
I'll ask my engineers to post the one he wrote. He did put more details into the article, so go check that. Here is a repo with a POC though: https://github.com/TheGejr/SpringShell
That’s not really a POC though. That’s not a Spring Application I can run and reproduce on. That’s just a py script.
A new spring release should come out today.
Earlier quoted context omitted.
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.
> 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…
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 is quite long. (Source - I have done my fair share of middleware and know tomcat source quite well)
Not sure why it's tagged JDK9+, but 'class' attribute is accessible on org.springframework.beans.BeanWrapperImpl.getLocalPropertyHandler() in JDK 8 also. It probably doesn't matter which JDK is being used, as long as this spring-beans dependency is used. Whether logging JSP exploit in JDK 8 or lower can be used is another question. However, since 'class' is accessible via request parameter, it's already bad and there…
JDK9+ is important because Spring already prevents access to `class.classloader`, but it can be worked around thanks to modules (i.e. `class.module.classloader` works).
It boggles my mind why this field is accessible at all and wasn't blocked in CVE-2010-1622.
"[11:59 BST] Spring Framework versions 5.3.18 and 5.2.20, which address the vulnerability, are now available on Maven Central. The release process for Spring Boot is in progress, but applications can already upgrade their Spring Framework version independently in order to be protected."
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 whole basis of this claim was a commit in a merged PR yeah?
https://spring.io/blog/2022/03/31/spring-framework-rce-early...
Earlier quoted context omitted.
That’s not really a POC though. That’s not a Spring Application I can run and reproduce on. That’s just a py script.
The PDF in the repo contains a simple Java sample that should be straightforward to build and run.
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…
Earlier quoted context omitted.
Lack of an assigned CVE is a really bad reason to discount anything, it's a bureucratic process with various tangential limitations, rules and delays.
CVEs are frequently created for minor issues, like the recent Jackson bug that has very specific (and not frequent) case.