чт, 31 мар. 2022 г. в 12:52, Mark Thomas <ma...@apache.org>: > > Hi all, > > My recent hardening fix to the class loader [1] provides mitigation for > a current Spring vulnerability [2]. > > While this is a Spring vulnerability, it may be the case for some users > that updating Tomcat is an easier mitigation path that updating Spring. > What are the community thoughts on cancelling the current releases, > re-tagging and releasing reasonably quickly? > > [1] > https://github.com/apache/tomcat/commit/1abcf3f4d741c824ae490009fe32ce300f10eddc > > [2] > https://github.com/apache/tomcat/commit/1abcf3f4d741c824ae490009fe32ce300f10eddc
Regarding [2] I think that you meant https://tanzu.vmware.com/security/cve-2022-22963 I found this article with more details: [3] https://securityonline.info/cve-2022-22963-spring-java-framework-0-day-remote-code-execution-vulerability-alert/ So we now have "setResources(WebResourceRoot)" without accompanying "getResources()" ... 1. I think that we can roll two votes in parallel, without cancelling the old one. So that in case getResources() is used somewhere, one could use the "old" release. Essentially it is not our vulnerability. Nothing is broken with the current RCs to cancel them. 2. I do not know about the actual attack POC, but I note that there are other public methods, and setters on the classloader. [3] talks that some setters were called. I see no way to remove it or protect some of those methods with a security manager, as they are part of the public API, as I see no way to distinguish it from a proper call by the application. So I think it is up to EL to close access to object -> getClass() -> getClassLoader() -> ... It is not really our issue. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
