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'm not too sure about the "portability" argument. If it was valid, then
we should add all proprietary features from all appservers right away. I
am not aware of JBoss having such a feature either (it does have
extensive CL configuration, though, but that is necessary due to its
default behavior).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
