-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark,
On 7/13/2011 2:28 PM, Mark Thomas wrote:
> No, since all that code runs in Tomcat's security context which has
> read everything permissions (by default) anyway. Logically, if a
> system admin doesn't want Tomcat to read those files, they wouldn't
> configure them in server.xml.
Yeah, I tend to agree... I was just trying to be creative which often
pays off when hunting for security vulnerabilities. :)
> What made the sendfile case different is that web application code
> (which in some circumstances may be untrusted) can control what
> sendfile does and it was doing it in such a way that the
> SecurityManager was bypassed.
Got it.
>> I don't think there's a disclosure here (specifying /etc/passwd for
>> a certificate file doesn't dump /etc/passwd) but there might be
>> opportunities for a JVM crash.
>
> Not a web application triggered one, which is what would be required
> for it to be a security vulnerability.
Good to know where the line is: if a webapp can attack the container,
it's a vulnerability. If the container itself can be configured
improperly, then that's just bad administration.
> A couple of other things that it is worth pointing out:
>
> 1. Performance Adding the SecurityManager checks has a noticeable
> performance hit. It my *very* ad-hoc testing, it was around 20%.
> However, sendfile + SecurityManager is still faster than no sendfile
> (with or without a SecurityManager)
Honestly, I see the use of a SecurityManager to be a trade-off in the
first place: security versus performance. It's too bad the JVM doens't
let you run some code under a SecurityManager and other code without one
(per Thread might make some most sense). Sure, you can get some code all
permissions, but the SM still has to determine that at runtime, which
has an associated cost.
> 2. A SecurityManager is not a complete defence against an untrusted
> web application. There is no way of stopping an untrusted web
> application doing this: <% while (1==1) { // burn that CPU } %>
>
> 3. Most users don't run untrusted web applications so this will not
> affect them.
I'm fortunate that I don't have to run untrusted code :) All of our
tight loops have been accidentally coded by our own team :)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4d7KUACgkQ9CaO5/Lv0PAOhACeMwbQN9q3JX+FcMBWXVq2h4OY
tO4AoJWTwuGhhgWabmbdHGIwE3FXFpIF
=IITe
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
