On 13/07/2011 17:14, Christopher Schultz wrote:
> All,
>
> Great catch to all who were involved in discovery and mitigation of this
> vulnerability.
Konstantin found the problems - he deserves most of the credit.
> Since the APR flavor of this vulnerability uses native code to crash the
> JVM and/or read files without asking the SecurityManager for permission,
> does that mean that the APR SSL configuration could be similarly
> attacked by specifying certificate file, etc. paths that shouldn't be
> allowed by the SecurityManager?
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.
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.
> 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.
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)
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
