Описание
ELSA-2017-1809: tomcat security update (IMPORTANT)
[0:7.0.69-12]
- Resolves: rhbz#1441487 CVE-2017-5648 tomcat: Calls to application listeners did not use the appropriate facade object
- Resolves: rhbz#1441480 CVE-2017-5647 tomcat: Incorrect handling of pipelined requests when send file was used
- Resolves: rhbz#1459746 CVE-2017-5664 tomcat: Security constrained bypass in error page mechanism
Обновленные пакеты
Oracle Linux 7
Oracle Linux x86_64
tomcat
7.0.69-12.el7_3
tomcat-admin-webapps
7.0.69-12.el7_3
tomcat-docs-webapp
7.0.69-12.el7_3
tomcat-el-2.2-api
7.0.69-12.el7_3
tomcat-javadoc
7.0.69-12.el7_3
tomcat-jsp-2.2-api
7.0.69-12.el7_3
tomcat-jsvc
7.0.69-12.el7_3
tomcat-lib
7.0.69-12.el7_3
tomcat-servlet-3.0-api
7.0.69-12.el7_3
tomcat-webapps
7.0.69-12.el7_3
Связанные CVE
Связанные уязвимости
While investigating bug 60718, it was noticed that some calls to application listeners in Apache Tomcat 9.0.0.M1 to 9.0.0.M17, 8.5.0 to 8.5.11, 8.0.0.RC1 to 8.0.41, and 7.0.0 to 7.0.75 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.
While investigating bug 60718, it was noticed that some calls to application listeners in Apache Tomcat 9.0.0.M1 to 9.0.0.M17, 8.5.0 to 8.5.11, 8.0.0.RC1 to 8.0.41, and 7.0.0 to 7.0.75 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.
While investigating bug 60718, it was noticed that some calls to application listeners in Apache Tomcat 9.0.0.M1 to 9.0.0.M17, 8.5.0 to 8.5.11, 8.0.0.RC1 to 8.0.41, and 7.0.0 to 7.0.75 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.
While investigating bug 60718, it was noticed that some calls to appli ...
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 h...