Fixed in Apache Tomcat 8.0.32

Note: The issues below were fixed in Apache Tomcat 8.0.31 but the release vote for the 8.0.31 release candidate did not pass. Therefore, although users must download 8.0.32 to obtain a version that includes fixes for these issues, version 8.0.31 is not included in the list of affected versions.

Low: Session Fixation CVE-2015-5346

When recycling the Request object to use for a new request, the requestedSessionSSL field was not recycled. This meant that a session ID provided in the next request to be processed using the recycled Request object could be used when it should not have been. This gave the client the ability to control the session ID. In theory, this could have been used as part of a session fixation attack but it would have been hard to achieve as the attacker would not have been able to force the victim to use the ‘correct’ Request object. It was also necessary for at least one web application to be configured to use the SSL session ID as the HTTP session ID. This is not a common configuration.

This was fixed in revisions 1713185 and 1723506.

This issue was identified by the Tomcat security team on 22 June 2014 and made public on 22 February 2016.

Affects: 8.0.0.RC1 to 8.0.30

Moderate: CSRF token leak CVE-2015-5351

The index page of the Manager and Host Manager applications included a valid CSRF token when issuing a redirect as a result of an unauthenticated request to the root of the web application. If an attacker had access to the Manager or Host Manager applications (typically these applications are only accessible to internal users, not exposed to the Internet), this token could then be used by the attacker to construct a CSRF attack.

This was fixed in revisions 1720658 and 1720660.

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

Affects: 8.0.0.RC1 to 8.0.30

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

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

Affects: 8.0.0.RC1 to 8.0.30

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 1726196 and 1726203.

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

Affects: 8.0.0.RC1 to 8.0.30

Moderate: Security Manager bypass CVE-2016-0763

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

ResourceLinkFactory.setGlobalContext() is a public method and was accessible to web applications even when running under a security manager. This allowed a malicious web application to inject a malicious global context that could in turn be used to disrupt other web applications and/or read and write data owned by other web applications.

This was fixed in revision 1725929.

This issue was identified by the Tomcat security team on 18 January 2016 and made public on 22 February 2016.

Affects: 8.0.0.RC1 to 8.0.30