tomcat6-6.0.24-111.AXS4

Apache Tomcat is a servlet container for the Java Servlet and JavaServer Pages (JSP) technologies.

Security Fix(es):

* A vulnerability was discovered in Tomcat's handling of pipelined requests when "Sendfile" was used. If sendfile processing completed quickly, it was possible for the Processor to be added to the processor cache twice. This could lead to invalid responses or information disclosure. (CVE-2017-5647)

* A vulnerability was discovered in the error page mechanism in Tomcat's DefaultServlet implementation. A crafted HTTP request could cause undesired side effects, possibly including the removal or replacement of the custom error page. (CVE-2017-5664)

* Two vulnerabilities were discovered in Tomcat where if a servlet context was configured with readonly=false and HTTP PUT requests were allowed, an attacker could upload a JSP file to that context and achieve code execution. (CVE-2017-12615, CVE-2017-12617)

CVE-2017-12615
When running Apache Tomcat 7.0.0 to 7.0.79 on Windows 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 crafted request. This JSP could then be requested and
any code it contained would be executed by the server.
CVE-2017-12617
When running Apache Tomcat versions 9.0.0.M1 to 9.0.0, 8.5.0 to
8.5.22, 8.0.0.RC1 to 8.0.46 and 7.0.0 to 7.0.81 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.
CVE-2017-5647
A bug in the handling of the pipelined requests in Apache Tomcat
9.0.0.M1 to 9.0.0.M18, 8.5.0 to 8.5.12, 8.0.0.RC1 to 8.0.42, 7.0.0 to
7.0.76, and 6.0.0 to 6.0.52, when send file was used, results 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.
CVE-2017-5664
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 of the file as if
processing a GET request, regardless of the actual HTTP method. The
Default Servlet in Apache Tomcat 9.0.0.M1 to 9.0.0.M20, 8.5.0 to
8.5.14, 8.0.0.RC1 to 8.0.43 and 7.0.0 to 7.0.77 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: (1) Unless explicitly coded otherwise, JSPs ignore the HTTP
method. JSPs used as error pages must must ensure that they handle
any error dispatch as a GET request, regardless of the actual method.
(2) 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.