==================================================================== CERT-Renater Note d'Information No. 2016/VULN070 _____________________________________________________________________ DATE : 23/02/2016 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Apache Tomcat versions 6, 7, 8, 9 prior to 6.0.45, 7.0.68, 8.0.32, 9.0.0.M3. ====================================================================== http://tomcat.apache.org/security-6.html http://tomcat.apache.org/security-7.html http://tomcat.apache.org/security-8.html http://tomcat.apache.org/security-9.html _____________________________________________________________________ CVE-2016-0763 Apache Tomcat Security Manager Bypass Severity: Moderate Vendor: The Apache Software Foundation Versions Affected: - - - Apache Tomcat 7.0.0 to 7.0.67 - - - Apache Tomcat 8.0.0.RC1 to 8.0.30 - - - Apache Tomcat 9.0.0.M1 to 9.0.0.M2 Description: ResourceLinkFactory.setGlobalContext() is a public method and was accessible by web applications running under a security manager without any checks. 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. Mitigation: Users of affected versions should apply one of the following mitigations - - - Upgrade to Apache Tomcat 9.0.0.M3 or later - - - Upgrade to Apache Tomcat 8.0.32 or later (8.0.31 has the fix but was not released) - - - Upgrade to Apache Tomcat 7.0.68 or later - - - Upgrade to Apache Tomcat 6.0.45 or later Credit: This issue was discovered by The Apache Tomcat Security Team. References: [1] http://tomcat.apache.org/security-9.html [2] http://tomcat.apache.org/security-8.html [3] http://tomcat.apache.org/security-7.html _____________________________________________________________________ CVE-2016-0714 Apache Tomcat Security Manager Bypass Severity: Moderate Vendor: The Apache Software Foundation Versions Affected: - - - Apache Tomcat 6.0.0 to 6.0.44 - - - Apache Tomcat 7.0.0 to 7.0.67 - - - Apache Tomcat 8.0.0.RC1 to 8.0.30 - - - Apache Tomcat 9.0.0.M1 - - - Earlier, unsupported Tomcat versions may be affected Description: 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. Mitigation: Users of affected versions should apply one of the following mitigations - - - Upgrade to Apache Tomcat 9.0.0.M3 or later (9.0.0.M2 has the fix but was not released) - - - Upgrade to Apache Tomcat 8.0.32 or later (8.0.31 has the fix but was not released) - - - Upgrade to Apache Tomcat 7.0.68 or later - - - Upgrade to Apache Tomcat 6.0.45 or later Credit: This issue was discovered by The Apache Tomcat Security Team. References: [1] http://tomcat.apache.org/security-9.html [2] http://tomcat.apache.org/security-8.html [3] http://tomcat.apache.org/security-7.html [4] http://tomcat.apache.org/security-6.html _____________________________________________________________________ CVE-2016-0706 Apache Tomcat Security Manager bypass Severity: Low Vendor: The Apache Software Foundation Versions Affected: - - - Apache Tomcat 6.0.0 to 6.0.44 - - - Apache Tomcat 7.0.0 to 7.0.67 - - - Apache Tomcat 8.0.0.RC1 to 8.0.30 - - - Apache Tomcat 9.0.0.M1 - - - Earlier, unsupported Tomcat versions may be affected Description: The StatusManagerServlet could be loaded by a web application when a security manager was configured. This servlet would then provide the 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. Mitigation: Users of affected versions should apply one of the following mitigations - - - Upgrade to Apache Tomcat 9.0.0.M3 or later (9.0.0.M2 has the fix but was not released) - - - Upgrade to Apache Tomcat 8.0.32 or later (8.0.31 has the fix but was not released) - - - Upgrade to Apache Tomcat 7.0.68 or later - - - Upgrade to Apache Tomcat 6.0.45 or later Credit: This issue was discovered by The Apache Tomcat Security Team. References: [1] http://tomcat.apache.org/security-9.html [2] http://tomcat.apache.org/security-8.html [3] http://tomcat.apache.org/security-7.html [4] http://tomcat.apache.org/security-6.html _____________________________________________________________________ CVE-2015-5351 Apache Tomcat CSRF token leak Severity: Moderate Vendor: The Apache Software Foundation Versions Affected: - - - Apache Tomcat 7.0.1 to 7.0.67 - - - Apache Tomcat 8.0.0.RC1 to 8.0.31 - - - Apache Tomcat 9.0.0.M1 Description: 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. This token could then be used by an attacker to construct a CSRF attack. Mitigation: Users of affected versions should apply one of the following mitigations - - - Upgrade to Apache Tomcat 9.0.0.M3 or later (9.0.0.M2 has the fix but was not released) - - - Upgrade to Apache Tomcat 8.0.32 or later (8.0.31 has the fix but was not released) - - - Upgrade to Apache Tomcat 7.0.68 or later Credit: This issue was discovered by the Apache Tomcat security team. References: [1] http://tomcat.apache.org/security-9.html [2] http://tomcat.apache.org/security-8.html [3] http://tomcat.apache.org/security-7.html _____________________________________________________________________ CVE-2015-5346 Apache Tomcat Session fixation Severity: Low Vendor: The Apache Software Foundation Versions Affected: - - - Apache Tomcat 7.0.5 to 7.0.65 - - - Apache Tomcat 8.0.0.RC1 to 8.0.30 - - - Apache Tomcat 9.0.0.M1 Description: 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. Mitigation: Users of affected versions should apply one of the following mitigations - - - Upgrade to Apache Tomcat 9.0.0.M3 or later (9.0.0.M2 has the fix but was not released) - - - Upgrade to Apache Tomcat 8.0.30 or later - - - Upgrade to Apache Tomcat 7.0.67 or later (7.0.66 has the fix but was not released) Credit: This issue was discovered by the Apache Tomcat security team. References: [1] http://tomcat.apache.org/security-9.html [2] http://tomcat.apache.org/security-8.html [3] http://tomcat.apache.org/security-7.html _____________________________________________________________________ CVE-2015-5345 Apache Tomcat Directory disclosure Severity: Low Vendor: The Apache Software Foundation Versions Affected: - - - Apache Tomcat 6.0.0 to 6.0.44 - - - Apache Tomcat 7.0.0 to 7.0.66 - - - Apache Tomcat 8.0.0.RC1 to 8.0.29 - - - Apache Tomcat 9.0.0.M1 - - - Earlier, unsupported Tomcat versions may be affected Description: 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 to 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 [1] 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. Mitigation: Users of affected versions should apply one of the following mitigations - - - Upgrade to Apache Tomcat 9.0.0.M3 or later (9.0.0.M2 has the fix but was not released) - - - Upgrade to Apache Tomcat 8.0.30 or later - - - Upgrade to Apache Tomcat 7.0.67 or later - - - Upgrade to Apache Tomcat 6.0.45 or later Credit: This issue was discovered by Mark Koek of QCSec. References: [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=58765 [2] http://tomcat.apache.org/security-9.html [3] http://tomcat.apache.org/security-8.html [4] http://tomcat.apache.org/security-7.html [5] http://tomcat.apache.org/security-6.html _____________________________________________________________________ CVE-2015-5174 Apache Tomcat Limited Directory Traversal Severity: Low Vendor: The Apache Software Foundation Versions Affected: - - - Apache Tomcat 6.0.0 to 6.0.44 - - - Apache Tomcat 7.0.0 to 7.0.64 - - - Apache Tomcat 8.0.0.RC1 to 8.0.26 - - - Apache Tomcat 9 is not affected - - - Earlier, unsupported Tomcat versions may be affected Description: 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. Mitigation: Users of affected versions should apply one of the following mitigations - - - Upgrade to Apache Tomcat 8.0.27 or later - - - Upgrade to Apache Tomcat 7.0.65 or later - - - Upgrade to Apache Tomcat 6.0.45 or later Credit: This issue was discovered by the Apache Tomcat security team. References: [1] http://tomcat.apache.org/security-9.html [2] http://tomcat.apache.org/security-8.html [3] http://tomcat.apache.org/security-7.html [4] http://tomcat.apache.org/security-6.html ========================================================== Serveur de référence du CERT-Renater https://services.renater.fr/ssi/ ========================================================== + CERT-RENATER | tel : 01-53-94-20-44 + + 23 - 25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email: cert@support.renater.fr + ==========================================================