https://bz.apache.org/bugzilla/show_bug.cgi?id=69752
--- Comment #4 from Don't show my email <apa...@resellerdesktop.de> ---
can you imagine even one intended situation where the admin chooses "" instead
of an absolute path to expose his config willingly to the public?
the least that should be handled as "unintendend mistake". if one sets the
appbase willingly to a harmfull content.. ok, we could talk about it, but it
would still be a bad idea to allow that. ie "/" that would hurt a lot.
a pathbased protection is not that complex:
if absPath() is inside CATALINAHOME, but NOT INSIDE CATALINAHOME/WEBAPPS the
user should force this i.E. with "force=true"
some paths like /etc should also not allowed for obvious reasons.
this would be a reasonable compromise between stupidity and safety, but it
could break some existing installations, so it's to be introduced on a major
release, not a minor release.
if you need proofe that accepting "" is a bad idea use google "tomcat expose
conf" and you will find unintended mistakes. that was the way i found the
source for the behaviour.
Secure design means protecting against harmfull configs as well. remember back
when traversal attacks got mitigated: someone could have said "dont give the
tomcat process the rights to read that content upwards" but instead server devs
decided to disallow path access outside the webapp, wphich was good.
I would reduce this to:
do not accept appbasepath if appbase.abspath() == $CATALINAHOME/{conf}
about your relative path model:
is appbase="/" the real abs root, cause it's also a valid relative path within
the catalinahomepath. what has priority here? (it is bad in both cases) .
google had a mantra once: do not harm. please consider this.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
