Apache Tomcat found to suffer from security bypass vulnerability

Vendor reports that the ‘sendfile’ vulnerability may be used to perform a security bypass or a DoS when using a security manager.

A security vulnerability and associated security issue has been identified in Apache Tomcat by the Tomcat vulnerability team. This can be exploited to bypass restrictions and/or cause denial of service (DoS). The issue stems from Tomcat not properly verifying ‘sendfile’ request attributes, when being run under a security manager. It can be used by malicious Web applications to bypass local security restrictions. This vulnerability is the result of improper handling of ‘sendfile’ requests with invalid start or endpoints, which can be exploited to crash the Java Virtual Machine (JVM) running Tomcat.

 The ‘sendfile’ support in Tomcat is used to transfer large static files using the HTTP NIO and HTTP APR connectors. ‘sendfile’, which is used automatically for all ‘DefaultServerlet’ content, is also used by Web applications through setting request attributes. These request attributes are not validated in Tomcat. When running under a security manager, this may allow malicious Web apps to circumvent the security manager’s protection to access locked files or to crash the JVM.

The vulnerabilities can only occur when the HTTP NIO or HTTP APR connector is used to with ‘sendfile’ enabled for the connector (This is the default setting). Under this configuration when the security manager is used to limit untrusted applications, malicious untrusted applications may exploit the ‘sendfile’ flaw to bypass restrictions.

These security holes affect Tomcat versions 5.x, 6.x and 7.x. The proposed solution is a vendor workaround, which requires an update to version 5.5.34, 6.0.33, or 7.0.19 where applicable. The flaw (CVE-2011-2526) has a security rating of not critical. A patch has been proposed by the vendor for versions 5.x and versions 6.x.

The issue was reported by infosec research firm Secunia in a security alert. It was originally disclosed to the public on the vendor website on July 13, 2011.

Read more on Data breach incident management and recovery