Mark Thomas wrote:
Remy Maucherat wrote:
Tim Funk wrote:
2) If a deploy tool is used which is doing checks - adding an extra
check to allow/deny/restrict scope should not be too hard to do. Since
users can disable symlink checks in the same class (FileDirContext) -
the same exposure could be had with a little more effort.
I'm not trying to hand wave the concerns away with the previous 2
points. I've thought a while about how I can exploit this patch and
most examples relied on assumptions which if the assumption were true
- your system would have already been compromised.
I tested with the security manager, and it doesn't behave correctly.
If the context.xml inside a webapp is:
<Context>
<Resources className="org.apache.naming.resources.FileDirContext"
docBase="c:/foo" aliases="/mysecretpath/=c:/" />
</Context>
The docBase hack attempt doesn't do anything (it's overwritten, I
think), but the security manager does not prevent browsing the HD as the
policy grants all permissions to all JARs in lib.
I don't see a problem with including the feature, but the current
implmentation needs some work to resolve this bypassing of the security
manager.
I haven't looked at the code so I don't know how easy it will be to fix.
If it looks like it will take some time, then I would prefer that the
patch was reverted until the new version was ready.
I think this should be doable by adding some sort of security check. As
others have stated, the root issue is that all files in lib are given
all permissions (not entirely bad, it has the advantage of being able to
use anything in server.xml without headaches), and there are ways to fix
it by setting a more restrictive policy. It is true that other
components could allow similar problems, but I am not aware of any at
the moment (maybe the logging could allow writing things, although this
would most likely be heavily constrained by the user which is used to
run Tomcat - not root), and they did sound a lot less explicit than this
simple absolute redirection to somewhere else on the filesystem.
Overall, the review process I discussed earlier would make it easy to
discuss this sort of patch. That being said, I'm on vacation this week.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
