You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2011/07/13 17:33:22 UTC
[SECURITY] CVE-2011-2526 Apache Tomcat Information disclosure and
availability vulnerabilities
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
CVE-2011-2526: Apache Tomcat Information disclosure and availability
vulnerabilities
Severity: low
Vendor:
The Apache Software Foundation
Versions Affected:
Tomcat 7.0.0 to 7.0.18
Tomcat 6.0.0 to 6.0.32
Tomcat 5.5.0 to 5.0.33
Previous, unsupported versions may be affected
Additionally, these vulnerabilities only occur when all of the following
are true:
a) untrusted web applications are being used
b) the SecurityManager is used to limit the untrusted web applications
c) the HTTP NIO or HTTP APR connector is used
d) sendfile is enabled for the connector (this is the default)
Description:
Tomcat provides support for sendfile with the HTTP NIO and HTTP APR
connectors. sendfile is used automatically for content served via the
DefaultServlet and deployed web applications may use it directly via
setting request attributes. These request attributes were not validated.
When running under a security manager, this lack of validation allowed a
malicious web application to do one or more of the following that would
normally be prevented by a security manager:
a) return files to users that the security manager should make inaccessible
b) terminate (via a crash) the JVM
Mitigation:
Affected users of all versions can mitigate these vulnerabilities by
taking any of the following actions:
a) undeploy untrusted web applications
b) switch to the HTTP BIO connector (which does not support sendfile)
c) disable sendfile be setting useSendfile="false" on the connector
d) apply the patch(es) listed on the Tomcat security pages (see references)
e) upgrade to a version where the vulnerabilities have been fixed
Tomcat 7.0.x users may upgrade to 7.0.19 or later once released
Tomcat 6.0.x users may upgrade to 6.0.33 or later once released
Tomcat 5.5.x users may upgrade to 5.5.34 or later once released
Example:
Exposing the first 1000 bytes of /etc/passwd
HttpServletRequest.setAttribute(
"org.apache.tomcat.sendfile.filename","/etc/passwd");
HttpServletRequest.setAttribute(
"org.apache.tomcat.sendfile.start",Long.valueOf(0));
HttpServletRequest.setAttribute(
"org.apache.tomcat.sendfile.end",Long.valueOf(1000));
Specifying a end point after the end of the file will trigger a JVM
crash with the HTTP APR connector and an infinite loop with the HTTP NIO
connector.
Credit:
These issues were identified by the Tomcat security team.
References:
http://tomcat.apache.org/security.html
http://tomcat.apache.org/security-7.html
http://tomcat.apache.org/security-6.html
http://tomcat.apache.org/security-5.html
The Apache Tomcat Security Team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOHbrCAAoJEBDAHFovYFnnUZsQANIh02dK4r0cYCwsD59Xvg0R
cCpx0MCzsrVBKU/fJ5nQtVTtZnOVfH2PnZBPFlYxQXpBCgIQh+ZIp9ntGdSNP0kH
e7XgHaG6NipfIPusnQyH8yYmcfRl4BDnQdHyrl1JqApDtqnzPJ4Re9SVQC5VymJP
i9DlvuV4atAdSCgOZzBb3+wMV0uoZqjXcUZrQEXCYBhtGFtOQM/JyMUa7iu5+FhI
AuUchlHw3N+nZ+b4QeXGdFowHMTlJoj0gv5eMCEMVfiaoM5COcaQYBRQxkbNhkfN
7zkcKKyDG2ARIJ7WB3Ncj7A4RfF2KY98q69px6RU2ho8umOycl32dw3wT1AtPWUx
3TkTgkN4FXDprCLp1r/csbYO15GSoI0selWzKxmOOuMIIamQ36HreUInZzXohuOJ
VSdR/LBekdfiLNkNtIwK7oeaZoYqPT14F15C+gkzw8a7ETzN6kyYwZz2+dnnWvxM
lV5WhEksulVfrfro6OBFI4k4KVyCq/QYRUH2WfyaRyUhRB8of6tnweB46upzzoAU
+YtyLPimURofJbcw4Ut4VBvjVJTdts3air32vCKxpfnjdn9Gd3GH3phjrsYzJHTl
fg3RcqrmV9I0gxLn5oWIMx17gOGpFOgSwMyGgm/WEJLyiEV5suSPFVjMFq3znj+7
zAlePYK10YSe5XiZ9g8F
=MeHU
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY] CVE-2011-2526 Apache Tomcat Information disclosure
and availability vulnerabilities
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY] CVE-2011-2526 Apache Tomcat Information disclosure
and availability vulnerabilities
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY] CVE-2011-2526 Apache Tomcat Information disclosure
and availability vulnerabilities
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All,
Great catch to all who were involved in discovery and mitigation of this
vulnerability.
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?
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.
- -chris
On 7/13/2011 11:33 AM, Mark Thomas wrote:
> CVE-2011-2526: Apache Tomcat Information disclosure and availability
> vulnerabilities
>
> Severity: low
>
> Vendor: The Apache Software Foundation
>
> Versions Affected: Tomcat 7.0.0 to 7.0.18 Tomcat 6.0.0 to 6.0.32
> Tomcat 5.5.0 to 5.0.33 Previous, unsupported versions may be
> affected Additionally, these vulnerabilities only occur when all of
> the following are true: a) untrusted web applications are being used
> b) the SecurityManager is used to limit the untrusted web
> applications c) the HTTP NIO or HTTP APR connector is used d)
> sendfile is enabled for the connector (this is the default)
>
> Description: Tomcat provides support for sendfile with the HTTP NIO
> and HTTP APR connectors. sendfile is used automatically for content
> served via the DefaultServlet and deployed web applications may use
> it directly via setting request attributes. These request attributes
> were not validated. When running under a security manager, this lack
> of validation allowed a malicious web application to do one or more
> of the following that would normally be prevented by a security
> manager: a) return files to users that the security manager should
> make inaccessible b) terminate (via a crash) the JVM
>
> Mitigation: Affected users of all versions can mitigate these
> vulnerabilities by taking any of the following actions: a) undeploy
> untrusted web applications b) switch to the HTTP BIO connector (which
> does not support sendfile) c) disable sendfile be setting
> useSendfile="false" on the connector d) apply the patch(es) listed on
> the Tomcat security pages (see references) e) upgrade to a version
> where the vulnerabilities have been fixed Tomcat 7.0.x users may
> upgrade to 7.0.19 or later once released Tomcat 6.0.x users may
> upgrade to 6.0.33 or later once released Tomcat 5.5.x users may
> upgrade to 5.5.34 or later once released
>
> Example: Exposing the first 1000 bytes of /etc/passwd
> HttpServletRequest.setAttribute(
> "org.apache.tomcat.sendfile.filename","/etc/passwd");
> HttpServletRequest.setAttribute(
> "org.apache.tomcat.sendfile.start",Long.valueOf(0));
> HttpServletRequest.setAttribute(
> "org.apache.tomcat.sendfile.end",Long.valueOf(1000)); Specifying a
> end point after the end of the file will trigger a JVM crash with the
> HTTP APR connector and an infinite loop with the HTTP NIO connector.
>
> Credit: These issues were identified by the Tomcat security team.
>
> References: http://tomcat.apache.org/security.html
> http://tomcat.apache.org/security-7.html
> http://tomcat.apache.org/security-6.html
> http://tomcat.apache.org/security-5.html
>
> The Apache Tomcat Security Team
>
>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4dxHoACgkQ9CaO5/Lv0PDykgCeNvC61SVMsawzVre/6ZxvR/+2
tvoAnRyoZQd14OJSo7+ExfWKSMnBTRex
=jpLx
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY] CVE-2011-2526 Apache Tomcat Information disclosure
and availability vulnerabilities
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All,
Great catch to all who were involved in discovery and mitigation of this
vulnerability.
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?
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.
- -chris
On 7/13/2011 11:33 AM, Mark Thomas wrote:
> CVE-2011-2526: Apache Tomcat Information disclosure and availability
> vulnerabilities
>
> Severity: low
>
> Vendor: The Apache Software Foundation
>
> Versions Affected: Tomcat 7.0.0 to 7.0.18 Tomcat 6.0.0 to 6.0.32
> Tomcat 5.5.0 to 5.0.33 Previous, unsupported versions may be
> affected Additionally, these vulnerabilities only occur when all of
> the following are true: a) untrusted web applications are being used
> b) the SecurityManager is used to limit the untrusted web
> applications c) the HTTP NIO or HTTP APR connector is used d)
> sendfile is enabled for the connector (this is the default)
>
> Description: Tomcat provides support for sendfile with the HTTP NIO
> and HTTP APR connectors. sendfile is used automatically for content
> served via the DefaultServlet and deployed web applications may use
> it directly via setting request attributes. These request attributes
> were not validated. When running under a security manager, this lack
> of validation allowed a malicious web application to do one or more
> of the following that would normally be prevented by a security
> manager: a) return files to users that the security manager should
> make inaccessible b) terminate (via a crash) the JVM
>
> Mitigation: Affected users of all versions can mitigate these
> vulnerabilities by taking any of the following actions: a) undeploy
> untrusted web applications b) switch to the HTTP BIO connector (which
> does not support sendfile) c) disable sendfile be setting
> useSendfile="false" on the connector d) apply the patch(es) listed on
> the Tomcat security pages (see references) e) upgrade to a version
> where the vulnerabilities have been fixed Tomcat 7.0.x users may
> upgrade to 7.0.19 or later once released Tomcat 6.0.x users may
> upgrade to 6.0.33 or later once released Tomcat 5.5.x users may
> upgrade to 5.5.34 or later once released
>
> Example: Exposing the first 1000 bytes of /etc/passwd
> HttpServletRequest.setAttribute(
> "org.apache.tomcat.sendfile.filename","/etc/passwd");
> HttpServletRequest.setAttribute(
> "org.apache.tomcat.sendfile.start",Long.valueOf(0));
> HttpServletRequest.setAttribute(
> "org.apache.tomcat.sendfile.end",Long.valueOf(1000)); Specifying a
> end point after the end of the file will trigger a JVM crash with the
> HTTP APR connector and an infinite loop with the HTTP NIO connector.
>
> Credit: These issues were identified by the Tomcat security team.
>
> References: http://tomcat.apache.org/security.html
> http://tomcat.apache.org/security-7.html
> http://tomcat.apache.org/security-6.html
> http://tomcat.apache.org/security-5.html
>
> The Apache Tomcat Security Team
>
>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4dxHoACgkQ9CaO5/Lv0PDykgCeNvC61SVMsawzVre/6ZxvR/+2
tvoAnRyoZQd14OJSo7+ExfWKSMnBTRex
=jpLx
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org