Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id A990D200D11 for ; Mon, 2 Oct 2017 13:13:35 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id A80A41609DE; Mon, 2 Oct 2017 11:13:35 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 533891609EF for ; Mon, 2 Oct 2017 13:13:33 +0200 (CEST) Received: (qmail 77446 invoked by uid 500); 2 Oct 2017 11:13:26 -0000 Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Developers List" Delivered-To: mailing list dev@tomcat.apache.org Received: (qmail 77364 invoked by uid 99); 2 Oct 2017 11:13:26 -0000 Received: from Unknown (HELO svn01-us-west.apache.org) (209.188.14.144) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Oct 2017 11:13:26 +0000 Received: from svn01-us-west.apache.org (localhost [127.0.0.1]) by svn01-us-west.apache.org (ASF Mail Server at svn01-us-west.apache.org) with ESMTP id 5EF533A04A5 for ; Mon, 2 Oct 2017 11:13:23 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r1810336 [3/4] - in /tomcat/site/trunk: docs/security-7.html docs/security-8.html docs/security-9.html xdocs/security-7.xml xdocs/security-8.xml xdocs/security-9.xml Date: Mon, 02 Oct 2017 11:13:19 -0000 To: dev@tomcat.apache.org From: markt@apache.org X-Mailer: svnmailer-1.0.9 Message-Id: <20171002111323.5EF533A04A5@svn01-us-west.apache.org> archived-at: Mon, 02 Oct 2017 11:13:35 -0000 Modified: tomcat/site/trunk/docs/security-8.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-8.html?rev=1810336&r1=1810335&r2=1810336&view=diff ============================================================================== --- tomcat/site/trunk/docs/security-8.html (original) +++ tomcat/site/trunk/docs/security-8.html Mon Oct 2 11:13:19 2017 @@ -1,331 +1,328 @@ - - - - Apache Tomcat® - Apache Tomcat 8 vulnerabilities - - - -
-
- -
-
-
-
-
- -
-
-
-
-

Content

-

Table of Contents

-
- - - -
-

Apache Tomcat 8.x vulnerabilities

-
- -

- This page lists all security vulnerabilities fixed in released versions + + + +Apache Tomcat® - Apache Tomcat 8 vulnerabilities + + + +

+
+ +
+
+
+
+
+ +
+
+
+
+

Content

+

Table of Contents

+
+ + + +
+

Apache Tomcat 8.x vulnerabilities

+
+ +

This page lists all security vulnerabilities fixed in released versions of Apache Tomcat 8.x. Each vulnerability is given a security impact rating by the Apache Tomcat security team — please note that this rating may vary from platform to platform. We also list the versions of Apache Tomcat the flaw is known to affect, and where a flaw has not been verified list the - version with a question mark. -

- -

- Note: Vulnerabilities that are not Tomcat vulnerabilities + version with a question mark.

+ + +

+Note: Vulnerabilities that are not Tomcat vulnerabilities but have either been incorrectly reported against Tomcat or where Tomcat - provides a workaround are listed at the end of this page. -

- -

- Please note that binary patches are never provided. If you need to + provides a workaround are listed at the end of this page.

+ + +

Please note that binary patches are never provided. If you need to apply a source code patch, use the building instructions for the Apache Tomcat version that you are using. For Tomcat 8.0 those are building.html and @@ -333,815 +330,882 @@ Both files can be found in the webapps/docs subdirectory of a binary distributive. You may also want to review the Security Considerations - page in the documentation. -

- -

- If you need help on building or configuring Tomcat or other help on + page in the documentation.

+ + +

If you need help on building or configuring Tomcat or other help on following the instructions to mitigate the known vulnerabilities listed here, please send your questions to the public Tomcat Users mailing list -

- -

- If you have encountered an unlisted security vulnerability or other +

+ + +

If you have encountered an unlisted security vulnerability or other unexpected behaviour that has security impact, or if the descriptions here are incomplete, please report them privately to the Tomcat Security Team. Thank you. +

+ + +
+

+TBD October 2017 Fixed in Apache Tomcat 8.0.47

+
+ -

- -
-

- TBD October 2017 Fixed in Apache Tomcat 8.0.47 -

-
- -

- Important: Remote Code Execution +

+Important: Remote Code Execution CVE-2017-12617 -

- -

- When running with HTTP PUTs enabled (e.g. via setting the - readonly initialisation parameter of the Default to false) - it was possible to upload a JSP file to the server via a specially +

+ + +

When running with HTTP PUTs enabled (e.g. via setting the + readonly initialisation parameter of the Default servlet to + false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it - contained would be executed by the server. -

- -

- This was fixed in revision 1809921. -

- -

This issue was first reported publicly followed by multiple reports to + contained would be executed by the server.

+ + +

This was fixed in revision 1809921.

+ + +

This issue was first reported publicly followed by multiple reports to the Apache Tomcat Security Team on 20 September 2017.

- -

Affects: 8.0.0.RC1 to 8.0.46

- -
-

- 1 October 2017 Fixed in Apache Tomcat 8.5.23 -

-
- -

- Important: Remote Code Execution + + +

Affects: 8.0.0.RC1 to 8.0.46

+ + +
+

+1 October 2017 Fixed in Apache Tomcat 8.5.23

+
+ + +

+Important: Remote Code Execution CVE-2017-12617 -

- -

- When running with HTTP PUTs enabled (e.g. via setting the - readonly initialisation parameter of the Default to false) - it was possible to upload a JSP file to the server via a specially +

+ + +

When running with HTTP PUTs enabled (e.g. via setting the + readonly initialisation parameter of the Default servlet to + false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it - contained would be executed by the server. -

- -

- This was fixed in revisions 1809673, + contained would be executed by the server.

+ + +

This was fixed in revisions 1809673, 1809675 and - 1809896. -

- -

This issue was first reported publicly followed by multiple reports to + 1809896.

+ + +

This issue was first reported publicly followed by multiple reports to the Apache Tomcat Security Team on 20 September 2017.

- -

Affects: 8.5.0 to 8.5.22

- -
-

- 1 July 2017 Fixed in Apache Tomcat 8.0.45 -

-
- -

- Moderate: Cache Poisoning + + +

Affects: 8.5.0 to 8.5.22

+ + +
+

+1 July 2017 Fixed in Apache Tomcat 8.0.45

+
+ + +

+Moderate: Cache Poisoning CVE-2017-7674 -

- -

The CORS Filter did not add an HTTP Vary header indicating that the +

+ + +

The CORS Filter did not add an HTTP Vary header indicating that the response varies depending on Origin. This permitted client and server side cache poisoning in some circumstances.

- -

- This was fixed in revision 1795815. -

- -

- The issue was reported as bug 61101 on 16 May 2017. The full + + +

This was fixed in revision 1795815.

+ + +

The issue was reported as bug 61101 on 16 May 2017. The full implications of this issue were identified by the Tomcat Security Team - the same day. This issue was made public on 10 August 2017. -

- -

Affects: 8.0.0.RC1 to 8.0.44

- -
-

- 26 June 2017 Fixed in Apache Tomcat 8.5.16 -

-
- -

- Important: Security Constraint Bypass + the same day. This issue was made public on 10 August 2017.

+ + +

Affects: 8.0.0.RC1 to 8.0.44

+ + +
+

+26 June 2017 Fixed in Apache Tomcat 8.5.16

+
+ + +

+Important: Security Constraint Bypass CVE-2017-7675 -

- -

The HTTP/2 implementation bypassed a number of security checks that +

+ + +

The HTTP/2 implementation bypassed a number of security checks that prevented directory traversal attacks. It was therefore possible to bypass security constraints using an specially crafted URL.

- -

- This was fixed in revision 1796091. -

- -

- The issue was originally reported as a failure to process URL path + + +

This was fixed in revision 1796091.

+ + +

The issue was originally reported as a failure to process URL path parameters in bug 61120 on 24 May 2017. The full implications of this issue were identified by the Tomcat Security Team the same day. - This issue was made public on 10 August 2017. -

- -

Affects: 8.5.0 to 8.5.15

- -

- Moderate: Cache Poisoning + This issue was made public on 10 August 2017.

+ + +

Affects: 8.5.0 to 8.5.15

+ + +

+Moderate: Cache Poisoning CVE-2017-7674 -

- -

The CORS Filter did not add an HTTP Vary header indicating that the +

+ + +

The CORS Filter did not add an HTTP Vary header indicating that the response varies depending on Origin. This permitted client and server side cache poisoning in some circumstances.

- -

- This was fixed in revision 1795814. -

- -

- The issue was reported as bug 61101 on 16 May 2017. The full + + +

This was fixed in revision 1795814.

+ + +

The issue was reported as bug 61101 on 16 May 2017. The full implications of this issue were identified by the Tomcat Security Team - the same day. This issue was made public on 10 August 2017. -

- -

Affects: 8.5.0 to 8.5.15

- -
-

- 16 May 2017 Fixed in Apache Tomcat 8.0.44 -

-
- + the same day. This issue was made public on 10 August 2017.

+ -

- Important: Security Constraint Bypass +

Affects: 8.5.0 to 8.5.15

+ + +
+

+16 May 2017 Fixed in Apache Tomcat 8.0.44

+
+ + +

+Important: Security Constraint Bypass CVE-2017-5664 -

- -

The error page mechanism of the Java Servlet Specification requires that, +

+ + +

The error page mechanism of the Java Servlet Specification requires that, when an error occurs and an error page is configured for the error that occurred, the original request and response are forwarded to the error page. This means that the request is presented to the error page with the original HTTP method.

- -

If the error page is a static file, expected behaviour is to serve content + + +

If the error page is a static file, expected behaviour is to serve content of the file as if processing a GET request, regardless of the actual HTTP method. Tomcat's Default Servlet did not do this. Depending on the original request this could lead to unexpected and undesirable results for static error pages including, if the DefaultServlet is configured to permit writes, the replacement or removal of the custom error page.

- -

Notes for other user provided error pages:

- -
    - -
  • Unless explicitly coded otherwise, JSPs ignore the HTTP method. + + +

    Notes for other user provided error pages:

    + +
      + +
    • Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.
      • - -
    • By default, the response generated by a Servlet does depend on the + +
    • By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.
      • - -
    - -

    - This was fixed in revisions 1793470 and - 1793489. -

    - -

    This issue was reported responsibly to the Apache Tomcat Security Team by + +

+ + +

This was fixed in revisions 1793470 and + 1793489.

+ + +

This issue was reported responsibly to the Apache Tomcat Security Team by Aniket Nandkishor Kulkarni from Tata Consultancy Services Ltd, Mumbai, India as a vulnerability that allowed the restrictions on OPTIONS and TRACE requests to be bypassed on 21 April 2017. The full implications of this issue were identified by the Tomcat Security Team on 24 April 2017. This issue was made public on 6 June 2017.

- -

Affects: 8.0.0.RC1 to 8.0.43

- -
-

- 10 May 2017 Fixed in Apache Tomcat 8.5.15 -

-
- + + +

Affects: 8.0.0.RC1 to 8.0.43

+ + +
+

+10 May 2017 Fixed in Apache Tomcat 8.5.15

+
+ -

- Important: Security Constraint Bypass +

+Important: Security Constraint Bypass CVE-2017-5664 -

- -

The error page mechanism of the Java Servlet Specification requires that, +

+ + +

The error page mechanism of the Java Servlet Specification requires that, when an error occurs and an error page is configured for the error that occurred, the original request and response are forwarded to the error page. This means that the request is presented to the error page with the original HTTP method.

- -

If the error page is a static file, expected behaviour is to serve content + + +

If the error page is a static file, expected behaviour is to serve content of the file as if processing a GET request, regardless of the actual HTTP method. Tomcat's Default Servlet did not do this. Depending on the original request this could lead to unexpected and undesirable results for static error pages including, if the DefaultServlet is configured to permit writes, the replacement or removal of the custom error page.

- -

Notes for other user provided error pages:

- -
    - -
  • Unless explicitly coded otherwise, JSPs ignore the HTTP method. + + +

    Notes for other user provided error pages:

    + +
      + +
    • Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.
      • - -
    • By default, the response generated by a Servlet does depend on the + +
    • By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.
      • - -
    - -

    - This was fixed in revisions 1793469 and - 1793488. -

    - -

    This issue was reported responsibly to the Apache Tomcat Security Team by + +

+ + +

This was fixed in revisions 1793469 and + 1793488.

+ + +

This issue was reported responsibly to the Apache Tomcat Security Team by Aniket Nandkishor Kulkarni from Tata Consultancy Services Ltd, Mumbai, India as a vulnerability that allowed the restrictions on OPTIONS and TRACE requests to be bypassed on 21 April 2017. The full implications of this issue were identified by the Tomcat Security Team on 24 April 2017. This issue was made public on 6 June 2017.

- -

Affects: 8.5.0 to 8.5.14

- -
-

- 2 April 2017 Fixed in Apache Tomcat 8.0.43 -

-
- -

- Important: Information Disclosure + + +

Affects: 8.5.0 to 8.5.14

+ + +
+

+2 April 2017 Fixed in Apache Tomcat 8.0.43

+
+ + +

+Important: Information Disclosure CVE-2017-5647 -

- -

A bug in the handling of the pipelined requests when send file was used +

+ + +

A bug in the handling of the pipelined requests when send file was used resulted in the pipelined request being lost when send file processing of the previous request completed. This could result in responses appearing to be sent for the wrong request. For example, a user agent that sent requests A, B and C could see the correct response for request A, the response for request C for request B and no response for request C.

- -

- This was fixed in revision 1788999. -

- -

This issue was identified by the Apache Tomcat Security Team on 20 + + +

This was fixed in revision 1788999.

+ + +

This issue was identified by the Apache Tomcat Security Team on 20 March 2017 and made public on 10 April 2017.

- -

Affects: 8.0.0.RC1 to 8.0.42

- -
-

- 30 March 2017 Fixed in Apache Tomcat 8.5.13 -

-
- -

- Important: Information Disclosure + + +

Affects: 8.0.0.RC1 to 8.0.42

+ + +
+

+30 March 2017 Fixed in Apache Tomcat 8.5.13

+
+ + +

+Important: Information Disclosure CVE-2017-5651 -

- -

The refactoring of the HTTP connectors for 8.5.x onwards, introduced a +

+ + +

The refactoring of the HTTP connectors for 8.5.x onwards, introduced a regression in the send file processing. If the send file processing completed quickly, it was possible for the Processor to be added to the processor cache twice. This could result in the same Processor being used for multiple requests which in turn could lead to unexpected errors and/or response mix-up.

- -

- This was fixed in revision 1788546. -

- -

This issue was identified by the Apache Tomcat Security Team on 24 + + +

This was fixed in revision 1788546.

+ + +

This issue was identified by the Apache Tomcat Security Team on 24 March 2017 and made public on 10 April 2017.

- -

Affects: 8.5.0 to 8.5.12

- -

- Important: Denial of Service + + +

Affects: 8.5.0 to 8.5.12

+ + +

+Important: Denial of Service CVE-2017-5650 -

- -

The handling of an HTTP/2 GOAWAY frame for a connection did not close +

+ + +

The handling of an HTTP/2 GOAWAY frame for a connection did not close streams associated with that connection that were currently waiting for a WINDOW_UPDATE before allowing the application to write more data. These waiting streams each consumed a thread. A malicious client could therefore construct a series of HTTP/2 requests that would consume all available processing threads.

- -

- This was fixed in revision 1788480. -

- -

This issue was reported to the Apache Tomcat Security Team by Chun Han + + +

This was fixed in revision 1788480.

+ + +

This issue was reported to the Apache Tomcat Security Team by Chun Han Hsiao on 11 March 2017 and made public on 10 April 2017.

- -

Affects: 8.5.0 to 8.5.12

- -

- Important: Information Disclosure + + +

Affects: 8.5.0 to 8.5.12

+ + +

+Important: Information Disclosure CVE-2017-5647 -

- -

A bug in the handling of the pipelined requests when send file was used +

+ + +

A bug in the handling of the pipelined requests when send file was used resulted in the pipelined request being lost when send file processing of the previous request completed. This could result in responses appearing to be sent for the wrong request. For example, a user agent that sent requests A, B and C could see the correct response for request A, the response for request C for request B and no response for request C.

- -

- This was fixed in revision 1788932. -

- -

This issue was identified by the Apache Tomcat Security Team on 20 + + +

This was fixed in revision 1788932.

+ + +

This issue was identified by the Apache Tomcat Security Team on 20 March 2017 and made public on 10 April 2017.

- -

Affects: 8.5.0 to 8.5.12

- -
-

- 14 March 2017 Fixed in Apache Tomcat 8.0.42 -

-
- -

- Low: Information Disclosure + + +

Affects: 8.5.0 to 8.5.12

+ + +
+

+14 March 2017 Fixed in Apache Tomcat 8.0.42

+
+ + +

+Low: Information Disclosure CVE-2017-5648 -

- -

While investigating bug 60718, it was noticed that some calls to +

+ + +

While investigating bug 60718, it was noticed that some calls to application listeners did not use the appropriate facade object. When running an untrusted application under a SecurityManager, it was therefore possible for that untrusted application to retain a reference to the request or response object and thereby access and/or modify information associated with another web application.

- -

- This was fixed in revision 1785776. -

- -

This issue was identified by the Apache Tomcat Security Team on 20 + + +

This was fixed in revision 1785776.

+ + +

This issue was identified by the Apache Tomcat Security Team on 20 March 2017 and made public on 10 April 2017.

- -

Affects: 8.0.0.RC1 to 8.0.41

- -
-

- 13 March 2017 Fixed in Apache Tomcat 8.5.12 -

-
- -

- Low: Information Disclosure + + +

Affects: 8.0.0.RC1 to 8.0.41

+ + +
+

+13 March 2017 Fixed in Apache Tomcat 8.5.12

+
+ + +

+Low: Information Disclosure CVE-2017-5648 -

- -

While investigating bug 60718, it was noticed that some calls to +

+ + +

While investigating bug 60718, it was noticed that some calls to application listeners did not use the appropriate facade object. When running an untrusted application under a SecurityManager, it was therefore possible for that untrusted application to retain a reference to the request or response object and thereby access and/or modify information associated with another web application.

- -

- This was fixed in revision 1785775. -

- -

This issue was identified by the Apache Tomcat Security Team on 20 + + +

This was fixed in revision 1785775.

+ + +

This issue was identified by the Apache Tomcat Security Team on 20 March 2017 and made public on 10 April 2017.

- -

Affects: 8.5.0 to 8.5.11

- -
-

- 24 January 2017 Fixed in Apache Tomcat 8.0.41 -

-
- -

- Note: The issue below was fixed in Apache Tomcat 8.0.40 but the + + +

Affects: 8.5.0 to 8.5.11

+ + +
+

+24 January 2017 Fixed in Apache Tomcat 8.0.41

+
+ + +

+Note: The issue below was fixed in Apache Tomcat 8.0.40 but the release vote for the 8.0.40 release candidate did not pass. Therefore, although users must download 8.0.41 to obtain a version that includes the fix for this issue, version 8.0.40 is not included in the list of affected versions. -

- -

- Important: Information Disclosure +

+ + +

+Important: Information Disclosure CVE-2016-8745 -

- -

A bug in the error handling of the send file code for the NIO HTTP +

+ + +

A bug in the error handling of the send file code for the NIO HTTP connector resulted in the current Processor object being added to the Processor cache multiple times. This in turn meant that the same Processor could be used for concurrent requests. Sharing a Processor can result in information leakage between requests including, but not limited to, session ID and the response body.

- -

- This was fixed in revision 1777469. -

- -

This issue was identified as affecting 8.0.x by the Apache Tomcat Security + + +

This was fixed in revision 1777469.

+ + +

This issue was identified as affecting 8.0.x by the Apache Tomcat Security Team on 3 January 2016 and made public on 5 January 2017.

- -

Affects: 8.0.0.RC1 to 8.0.39

- -
-

- 16 January 2017 Fixed in Apache Tomcat 8.5.11 -

-
- -

- Note: The issue below was fixed in Apache Tomcat 8.5.10 but the + + +

Affects: 8.0.0.RC1 to 8.0.39

+ + +
+

+16 January 2017 Fixed in Apache Tomcat 8.5.11

+
+ + +

+Note: The issue below was fixed in Apache Tomcat 8.5.10 but the release vote for the 8.5.10 release candidate did not pass. Therefore, although users must download 8.5.11 to obtain a version that includes the fix for this issue, version 8.5.10 is not included in the list of affected versions. -

- -

- Moderate: Information Disclosure +

+ + +

+Moderate: Information Disclosure CVE-2016-8747 -

- -

The refactoring to make wider use of ByteBuffer introduced a regression +

+ + +

The refactoring to make wider use of ByteBuffer introduced a regression that could cause information to leak between requests on the same connection. When running behind a reverse proxy, this could result in information leakage between users. All HTTP connector variants are affected but HTTP/2 and AJP are not affected.

- -

- This was fixed in revision 1774166. -

- -

This issue was identified by the Apache Tomcat Security Team on 14 + + +

This was fixed in revision 1774166.

+ + +

This issue was identified by the Apache Tomcat Security Team on 14 December 2016 and made public on 13 March 2017.

- -

Affects: 8.5.7 to 8.5.9

- -
-

- 8 December 2016 Fixed in Apache Tomcat 8.5.9 -

-
- -

- Important: Information Disclosure + + +

Affects: 8.5.7 to 8.5.9

+ + +
+

+8 December 2016 Fixed in Apache Tomcat 8.5.9

+
+ + +

+Important: Information Disclosure CVE-2016-8745 -

- -

A bug in the error handling of the send file code for the NIO HTTP +

+ + +

A bug in the error handling of the send file code for the NIO HTTP connector resulted in the current Processor object being added to the Processor cache multiple times. This in turn meant that the same Processor could be used for concurrent requests. Sharing a Processor can result in information leakage between requests including, but not limited to, session ID and the response body.

- -

- This was fixed in revision 1771857. -

- -

This issue was identified by the Apache Tomcat Security Team on 8 December + + +

This was fixed in revision 1771857.

+ + +

This issue was identified by the Apache Tomcat Security Team on 8 December 2016 and made public on 12 December 2016.

- -

Affects: 8.5.0 to 8.5.8

- -
-

- 14 November 2016 Fixed in Apache Tomcat 8.0.39 -

-
- -

- Important: Remote Code Execution + + +

Affects: 8.5.0 to 8.5.8

+ + +
+

+14 November 2016 Fixed in Apache Tomcat 8.0.39

+
+ + +

+Important: Remote Code Execution CVE-2016-8735 -

- -

- The JmxRemoteLifecycleListener was not updated to take +

+ + +

The JmxRemoteLifecycleListener was not updated to take account of Oracle's fix for CVE-2016-3427. Therefore, Tomcat installations using this listener remained vulnerable to a similar remote code execution vulnerability. This issue has been rated as important rather than critical due to the small number of installations using this listener and that it would be highly unusual for the JMX ports to be - accessible to an attacker even when the listener is used. -

- -

- This was fixed in revision 1767656. -

- -

This issue was reported to the Apache Tomcat Security Team on 19 October + accessible to an attacker even when the listener is used.

+ + +

This was fixed in revision 1767656.

+ + +

This issue was reported to the Apache Tomcat Security Team on 19 October 2016 and made public on 22 November 2016.

- -

Affects: 8.0.0.RC1 to 8.0.38

- -

- Important: Information Disclosure + + +

Affects: 8.0.0.RC1 to 8.0.38

+ + +

+Important: Information Disclosure CVE-2016-6816 -

- -

The code that parsed the HTTP request line permitted invalid characters. +

+ + +

The code that parsed the HTTP request line permitted invalid characters. This could be exploited, in conjunction with a proxy that also permitted the invalid characters but with a different interpretation, to inject data into the HTTP response. By manipulating the HTTP response the attacker could poison a web-cache, perform an XSS attack and/or obtain sensitive information from requests other then their own.

- -

- This was fixed in revision 1767653. -

- -

This issue was reported to the Apache Tomcat Security Team on 11 + + +

This was fixed in revision 1767653.

+ + +

This issue was reported to the Apache Tomcat Security Team on 11 October 2016 and made public on 22 November 2016.

- -

Affects: 8.0.0.RC1 to 8.0.38

- -
-

- 8 November 2016 Fixed in Apache Tomcat 8.5.8 -

-
- -

- Note: The issues below were fixed in Apache Tomcat 8.5.7 but the + + +

Affects: 8.0.0.RC1 to 8.0.38

+ + +
+

+8 November 2016 Fixed in Apache Tomcat 8.5.8

+
+ + +

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

- +

+ -

- Important: Remote Code Execution +

+Important: Remote Code Execution CVE-2016-8735 -

- -

- The JmxRemoteLifecycleListener was not updated to take +

+ + +

The JmxRemoteLifecycleListener was not updated to take account of Oracle's fix for CVE-2016-3427. Therefore, Tomcat installations using this listener remained vulnerable to a similar remote code execution vulnerability. This issue has been rated as important rather than critical due to the small number of installations using this listener and that it would be highly unusual for the JMX ports to be - accessible to an attacker even when the listener is used. -

- -

- This was fixed in revision 1767646. -

- -

This issue was reported to the Apache Tomcat Security Team on 19 October + accessible to an attacker even when the listener is used.

+ + +

This was fixed in revision 1767646.

+ + +

This issue was reported to the Apache Tomcat Security Team on 19 October 2016 and made public on 22 November 2016.

- -

Affects: 8.5.0 to 8.5.6

- -

- Important: Denial of Service + + +

Affects: 8.5.0 to 8.5.6

+ + +

+Important: Denial of Service CVE-2016-6817 -

- -

The HTTP/2 header parser entered an infinite loop if a header was +

+ + +

The HTTP/2 header parser entered an infinite loop if a header was received that was larger than the available buffer. This made a denial of service attack possible.

- -

- This was fixed in revision 1765798. -

- -

- This issue was reported as 60232 on 10 October 2016 and the + + +

This was fixed in revision 1765798.

+ + +

This issue was reported as 60232 on 10 October 2016 and the security implications identified by the Apache Tomcat Security Team on - the same day. It was made public on 22 November 2016. -

- -

Affects: 8.5.0 to 8.5.6

- -

- Important: Information Disclosure + the same day. It was made public on 22 November 2016.

+ + +

Affects: 8.5.0 to 8.5.6

+ + +

+Important: Information Disclosure CVE-2016-6816 -

- -

The code that parsed the HTTP request line permitted invalid characters. +

+ + +

The code that parsed the HTTP request line permitted invalid characters. This could be exploited, in conjunction with a proxy that also permitted the invalid characters but with a different interpretation, to inject data into the HTTP response. By manipulating the HTTP response the attacker could poison a web-cache, perform an XSS attack and/or obtain sensitive information from requests other then their own.

- -

- This was fixed in revision 1767645. -

- -

This issue was reported to the Apache Tomcat Security Team on 11 + + +

This was fixed in revision 1767645.

+ + +

This issue was reported to the Apache Tomcat Security Team on 11 October 2016 and made public on 22 November 2016.

- -

Affects: 8.5.0 to 8.5.6

- -
-

- 5 September 2016 Fixed in Apache Tomcat 8.5.5 and 8.0.37 -

-
- + -

- Low: Unrestricted Access to Global Resources +

Affects: 8.5.0 to 8.5.6

+ + +
+

+5 September 2016 Fixed in Apache Tomcat 8.5.5 and 8.0.37

+
+ + +

+Low: Unrestricted Access to Global Resources CVE-2016-6797 -

- -

The ResourceLinkFactory did not limit web application access to global +

+ + +

The ResourceLinkFactory did not limit web application access to global JNDI resources to those resources explicitly linked to the web application. Therefore, it was possible for a web application to access any global JNDI resource whether an explicit ResourceLink had been configured or not.

- -

- This was fixed in revision 1757272 for + + +

This was fixed in revision 1757272 for 8.5.x and revision 1757273 for - 8.0.x. -

- -

This issue was identified by the Apache Tomcat Security Team on 18 + 8.0.x.

+ + +

This issue was identified by the Apache Tomcat Security Team on 18 January 2016 and made public on 27 October 2016.

- -

Affects: 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36

- -

- Low: Security Manager Bypass + + +

Affects: 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36

+ + +

+Low: Security Manager Bypass CVE-2016-6796 -

- -

A malicious web application was able to bypass a configured +

+ + +

A malicious web application was able to bypass a configured SecurityManager via manipulation of the configuration parameters for the JSP Servlet.

- -

- This was fixed in revisions 1758493 and + + +

This was fixed in revisions 1758493 and 1763233 for 8.5.x and revisions 1758494 and - 1763234for 8.0.x. -

- -

This issue was identified by the Apache Tomcat Security Team on 27 + 1763234for 8.0.x.

+ + +

This issue was identified by the Apache Tomcat Security Team on 27 December 2015 and made public on 27 October 2016.

- -

Affects: 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36

- -

- Low: System Property Disclosure + + +

Affects: 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36

+ + +

+Low: System Property Disclosure CVE-2016-6794 -

- -

When a SecurityManager is configured, a web application's ability to read +

+ + +

When a SecurityManager is configured, a web application's ability to read system properties should be controlled by the SecurityManager. Tomcat's system property replacement feature for configuration files could be used by a malicious web application to bypass the SecurityManager and read system properties that should not be visible.

- -

- This was fixed in revision 1754726 for + + +

This was fixed in revision 1754726 for 8.5.x and revision 1754727 for - 8.0.x. -

- -

This issue was identified by the Apache Tomcat Security Team on 27 + 8.0.x.

+ + +

This issue was identified by the Apache Tomcat Security Team on 27 December 2015 and made public on 27 October 2016.

- -

Affects: 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36

- -

- Low: Security Manager Bypass + + +

Affects: 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36

+ + +

+Low: Security Manager Bypass CVE-2016-5018 -

- -

A malicious web application was able to bypass a configured +

+ + +

A malicious web application was able to bypass a configured SecurityManager via a Tomcat utility method that was accessible to web applications.

- -

- This was fixed in revisions 1754900 and + + +

This was fixed in revisions 1754900 and 1760305 for 8.5.x and revisions 1754901 and - 1760307 for 8.0.x. -

- -

This issue was discovered by Alvaro Munoz and Alexander Mirosh of the HP + 1760307 for 8.0.x.

+ + [... 1333 lines stripped ...] --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org For additional commands, e-mail: dev-help@tomcat.apache.org