You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2022/04/22 13:00:10 UTC
[Bug 66025] New: WebappClassLoaderBase.getResources() needs partial replacements
https://bz.apache.org/bugzilla/show_bug.cgi?id=66025
Bug ID: 66025
Summary: WebappClassLoaderBase.getResources() needs partial
replacements
Product: Tomcat 9
Version: 9.0.62
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P2
Component: Servlet
Assignee: dev@tomcat.apache.org
Reporter: apache@froehlich-mail.net
Target Milestone: -----
Tomcat 9.0.62 deprecated the getResource() method of WebappClassLoaderBase and
at the same time made it always return null. It is a very hard step and I
cannot understand, why not instantly remove the method. If someone uses it, it
will fail with an NPE now soewhere at runtime, which is nothing better than
being uncompilable, but worse.
Anyway, virtually removing this method has some downsides, that need
compensation. We're using this method for a single purpose: calling
getContext(). And this is done for three purposes:
- getting the context's name via getName()
- resolving a resource path via getRealPath(String)
- getting the context's logger via getLogger()
There's a method in WebappClassLoaderBase.getContextName(). I suggest to stuff
this method with a simple String instead of extracting the name from
resources.getContext().getName(). This would be possible without any security
risk.
There should be some separate methods on the WebappClassLoaderBase to resolve
resource paths. We don't need the context for that. But the ClassLoader needs
ways to resolve paths the tomcat way. Especially resources, that are linked via
context.xml's <Resources> element must be recognized and resolved. The
getResource(String) and getResourceAsStream(String) methods (inherited from
ClassLoader) don't do that.
I guess a method getLogger() to return the context's logger would be a
no-risker.
What do you think? Would that be an option for you?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 66025] WebappClassLoaderBase.getResources() needs partial replacements
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=66025
Remy Maucherat <re...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |WONTFIX
Status|NEW |RESOLVED
--- Comment #1 from Remy Maucherat <re...@apache.org> ---
No, you are not supposed to access any of these internal APIs like this in the
first place.
This is exactly the problem we were facing: a call on the classloader (a
conveniently always available resource) happened to give access to internals.
So it had to be removed without warning when it became possible to use it with
remote scripting (in some specific cases involving Spring).
Maybe use a (Catalina) listener, populate Servlet context attributes with what
you need ?
Anyway, you should discuss it on the use list.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 66025] WebappClassLoaderBase.getResources() needs partial replacements
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=66025
--- Comment #2 from Marvin Fröhlich <ap...@froehlich-mail.net> ---
Don't you agree, that resolving resource paths is intrinsic for a classloader?
Is a logger a security relevant aspect?
Well, wouldn't it be sufficient to make provide these aspect via protected
methods?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 66025] WebappClassLoaderBase.getResources() needs partial replacements
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=66025
--- Comment #3 from Remy Maucherat <re...@apache.org> ---
(In reply to Marvin Fröhlich from comment #2)
> Don't you agree, that resolving resource paths is intrinsic for a
> classloader? Is a logger a security relevant aspect?
>
> Well, wouldn't it be sufficient to make provide these aspect via protected
> methods?
I don't understand. It is fine if WebappClassLoaderBase uses a WebResourceRoot
internally, however it turned out it is quite risky if it exposes it. Other
items could be exposed, but this is really not the place to do it, and this may
not be as safe as you think it is (for example with the Spring vuln, the
logging framework could become fully accessible allowing a remote user to log
unfiltered strings).
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 66025] WebappClassLoaderBase.getResources() needs partial replacements
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=66025
--- Comment #4 from Marvin Fröhlich <ap...@froehlich-mail.net> ---
What exactly do you mean by "expose"? A public getter? Would providing a
protected getter for the logger and context name and a protected method like
resolveResource(String) or resolvePath(String) or whatever be unsafe in Spring
vuln?
Of course you can always override it to elevate it to be public. But that's a
different story.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org