TTCSIRT-286.022620: TT-CSIRT ADVISORY- APACHE TOMCAT VULNERABILITIES
There are three vulnerabilities with Apache Tomcat with varying levels of severity.
Kindly see below for a summary of each vulnerability:
Operating System : Windows, UNIX variants (UNIX, Linux, OSX)
Impact/Access :
– Provide Misleading Information
– Remote/Unauthenticated
– Access Confidential Data
– Remote/Unauthenticated
– Unauthorised Access
– Remote/Unauthenticated Resolution:
Patch/Upgrade CVE Names: CVE-2020-1938 CVE-2020-1935 CVE-2019-17569
Original Bulletin:
https://www.mail-archive.com/users@tomcat.apache.org/msg134240.html
https://www.mail-archive.com/users@tomcat.apache.org/msg134239.html
https://www.mail-archive.com/users@tomcat.apache.org/msg134241.html
CVE-2020-1938 AJP Request Injection and potential Remote Code Execution
Severity: High
Vendor: The Apache Software Foundation
Versions Affected:
Apache Tomcat 9.0.0.M1 to 9.0.30
Apache Tomcat 8.5.0 to 8.5.50
Apache Tomcat 7.0.0 to 7.0.99
Description:
When using the Apache JServ Protocol (AJP), care must be taken whentrusting incoming connections to Apache Tomcat. Tomcat treats AJPconnections as having higher trust than, for example, a similar HTTPconnection.
If such connections are available to an attacker, they canbe exploited in ways that may be surprising.
Prior to Tomcat 9.0.31, 8.5.51 and 7.0.100, Tomcat shipped with an AJPConnector enabled by default that listened on all configured IPaddresses.
It was expected (and recommended in the security guide) that this Connector would be disabled if not required.
Prior to this vulnerability report, the known risks of an attacker beingable to access the AJP port directly were:
– bypassing security checks based on client IP address
– bypassing user authentication if Tomcat was configured to trust authentication data provided by the reverse proxy
This vulnerability report identified a mechanism that allowed the following:
– returning arbitrary files from anywhere in the web application including under the WEB-INF and META-INF directories or any other location reachable via ServletContext.getResourceAsStream()
– processing any file in the web application as a JSPFurther, if the web application allowed file upload and stored thosefiles within the web application (or the attacker was able to control the content of the web application by some other means) then this, alongwith the ability to process a file as a JSP, made remote code execution possible.
Mitigation:
It is important to note that mitigation is only required if an AJP portis accessible to untrusted users.
– If AJP support is not required, the Connector may be disabled e.g. by removing the AJP Connector element from the server.xml file
– If AJP support is required, untrusted users may be prevented from accessing the AJP port by one or more of the following means:
– configuring appropriate network firewall rules – configuring an explicit address attribute to the connector so that the Connector listens on a non-public interface – configuring a shared secret for the AJP connectionUsers wishing to take a defence-in-depth approach and block the vectorthat permits returning arbitrary files and execution as JSP may upgrade to:
– Apache Tomcat 9.0.31 or later
– Apache Tomcat 8.5.51 or later
– Apache Tomcat 7.0.100 or laterUsers should note that a number of changes were made to the default AJPConnector configuration in these versions to harden the defaultconfiguration.
The changes are:
– The AJP Connector is commented out in the provided server.xml file.
– The “requiredSecret” attribute has been renamed “secret” (the old name continues to work but is deprecated).
– A new attribute “secretRequired” has been added which defaults to “true”. When this attribute is “true”, the AJP Connector will not start unless a shared secret has been configured.
– The default listen address for the AJP Connector is now the loopback address.
It is likely that users upgrading to 9.0.31, 8.5.51 or 7.0.100 and later will need to make small changes to their configurations as a result.
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-2020-1935 HTTP Request Smuggling
Severity: Low
Vendor: The Apache Software Foundation
Versions Affected:Apache Tomcat 9.0.0.M1 to 9.0.30Apache Tomcat 8.5.0 to 8.5.50Apache Tomcat 7.0.0 to 7.0.99
Description:The HTTP header parsing code used an approach to end-of-line parsingthat allowed some invalid HTTP headers to be parsed as valid. This led to a possibility of HTTP Request Smuggling if Tomcat was located behinda reverse proxy that incorrectly handled the invalid Transfer-Encoding header in a particular manner. Such a reverse proxy is considered unlikely.
Mitigation:
– Upgrade to Apache Tomcat 9.0.31 or later
– Upgrade to Apache Tomcat 8.5.51 or later
– Upgrade to Apache Tomcat 7.0.100 or later
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-2019-17569 HTTP Request Smuggling
Severity: Low
Vendor: The Apache Software Foundation
Versions Affected:Apache Tomcat 9.0.28 to 9.0.30
Apache Tomcat 8.5.48 to 8.5.50
Apache Tomcat 7.0.98 to 7.0.99
Description:
The refactoring in 9.0.28, 8.5.48 and 7.0.98 introduced a regression. The result of the regression was that invalid Transfer-Encoding headers were incorrectly processed leading to a possibility of HTTP Request Smuggling if Tomcat was located behind a reverse proxy that incorrectly handled the invalid Transfer-Encoding header in a particular manner.Such a reverse proxy is considered unlikely.
Mitigation:
– Upgrade to Apache Tomcat 9.0.31 or later
– Upgrade to Apache Tomcat 8.5.51 or later
– Upgrade to Apache Tomcat 7.0.100 or later
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
The Trinidad and Tobago Cyber Security Incident Response Team (TTCSIRT) encourages users and administrators to review and apply the necessary updates.