Apache Tomcat found to suffer from security bypass vulnerability

News

Apache Tomcat found to suffer from security bypass vulnerability

SearchSecurity.in Staff

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

Continue Reading This Article

Enjoy this article as well as all of our content, including E-Guides, news, tips and more.

‘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.