On 31/03/2022 12:33, Konstantin Kolinko wrote:
чт, 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
No. This is a different issue.
I found this article with more details:
[3]
https://securityonline.info/cve-2022-22963-spring-java-framework-0-day-remote-code-execution-vulerability-alert/
That article is, unfortunately, mixing information from multiple issues.
So we now have "setResources(WebResourceRoot)"
without accompanying "getResources()" ...
Correct. But we never call getResources() so...
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.
True. It is slightly more work to run the existing releases to
completion rather than cancelling them but I can do that if that is the
consensus opinion. Personally, I'm happy with either option cancel or
continue. We have a little time so we can discuss this and decide what
to do while the votes run.
Essentially it is not our vulnerability. Nothing is broken with the
current RCs to cancel them.
Correct.
2. I do not know about the actual attack POC, but I note that there
are other public methods, and setters on the classloader.
I have more detail via $dayjob but I'm not going to disclose anything
that isn't already public.
I've reviewed the other public setters and the level of risk with those
methods looks to be much lower.
[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.
Agreed.
So I think it is up to EL to close access to object -> getClass() ->
getClassLoader() -> ...
It is not really our issue.
Agreed this isn't our issue but the PoC is leveraging Tomcat code so if
we can block it without breaking anything (which I think we can) then
doing so gives end users an alternative option to mitigate the issue.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
