Fixed in Apache Tomcat 6.0.45

Low: Limited directory traversal CVE-2015-5174

This issue only affects users running untrusted web applications under a security manager.

When accessing resources via the ServletContext methods getResource() getResourceAsStream() and getResourcePaths() the paths should be limited to the current web application. The validation was not correct and paths of the form “/…” were not rejected. Note that paths starting with “/…/” were correctly rejected. This bug allowed malicious web applications running under a security manager to obtain a directory listing for the directory in which the web application had been deployed. This should not be possible when running under a security manager. Typically, the directory listing that would be exposed would be for $CATALINA_BASE/webapps.

This was fixed in revision 1700900.

This issue was identified by the Tomcat security team on 12 August 2015 and made public on 22 February 2016.

Affects: 6.0.0 to 6.0.44

Low: Directory disclosure CVE-2015-5345

When accessing a directory protected by a security constraint with a URL that did not end in a slash, Tomcat would redirect to the URL with the trailing slash thereby confirming the presence of the directory before processing the security constraint. It was therefore possible for a user to determine if a directory existed or not, even if the user was not permitted to view the directory. The issue also occurred at the root of a web application in which case the presence of the web application was confirmed, even if a user did not have access.

The solution was to implement the redirect in the DefaultServlet so that any security constraints and/or security enforcing Filters were processed before the redirect. The Tomcat team recognised that moving the redirect could cause regressions so two new Context configuration options (mapperContextRootRedirectEnabled and mapperDirectoryRedirectEnabled) were introduced. The initial default was false for both since this was more secure. However, due to regressions such as Bug 58765 the default for mapperContextRootRedirectEnabled was later changed to true since it was viewed that the regression was more serious than the security risk of associated with being able to determine if a web application was deployed at a given path.

This was fixed in revisions 1715216 and 1717216.

This issue was identified by Mark Koek of QCSec on 12 October 2015 and made public on 22 February 2016.

Affects: 6.0.0 to 6.0.44

Low: Security Manager bypass CVE-2016-0706

This issue only affects users running untrusted web applications under a security manager.

The internal StatusManagerServlet could be loaded by a malicious web application when a security manager was configured. This servlet could then provide the malicious web application with a list of all deployed applications and a list of the HTTP request lines for all requests currently being processed. This could have exposed sensitive information from other web applications, such as session IDs, to the web application.

This was fixed in revision 1722802.

This issue was identified by the Tomcat security team on 27 December 2015 and made public on 22 February 2016.

Affects: 6.0.0 to 6.0.44

Moderate: Security Manager bypass CVE-2016-0714

This issue only affects users running untrusted web applications under a security manager.

Tomcat provides several session persistence mechanisms. The StandardManager persists session over a restart. The PersistentManager is able to persist sessions to files, a database or a custom Store. The cluster implementation persists sessions to one or more additional nodes in the cluster. All of these mechanisms could be exploited to bypass a security manager. Session persistence is performed by Tomcat code with the permissions assigned to Tomcat internal code. By placing a carefully crafted object into a session, a malicious web application could trigger the execution of arbitrary code.

This was fixed in revisions 1727166 and 1727182.

This issue was identified by the Tomcat security team on 12 November 2015 and made public on 22 February 2016.

Affects: 6.0.0 to 6.0.44