The (1) Manager and (2) Host Manager applications in Apache Tomcat 7.x before 7.0.68, 8.x before 8.0.31, and 9.x before 9.0.0.M2 establish sessions and send CSRF tokens for arbitrary new requests, which allows remote attackers to bypass a CSRF protection mechanism by using a token.
The session-persistence implementation in Apache Tomcat 6.x before 6.0.45, 7.x before 7.0.68, 8.x before 8.0.31, and 9.x before 9.0.0.M2 mishandles session attributes, which allows remote authenticated users to bypass intended SecurityManager restrictions and execute arbitrary code in a privileged context via a web application that places a crafted object in a session.
Session fixation vulnerability in Apache Tomcat 7.x before 7.0.66, 8.x before 8.0.30, and 9.x before 9.0.0.M2, when different session settings are used for deployments of multiple versions of the same web application, might allow remote attackers to hijack web sessions by leveraging use of a requestedSessionSSL field for an unintended request, related to CoyoteAdapter.java and Request.java.
Certain AJP protocol connector implementations in Apache Tomcat 7.0.0 through 7.0.20, 6.0.0 through 6.0.33, 5.5.0 through 5.5.33, and possibly other versions allow remote attackers to spoof AJP requests, bypass authentication, and obtain sensitive information by causing the connector to interpret a request body as a new request.
Unrestricted file upload vulnerability in Apache Tomcat 7.x before 7.0.40, in certain situations involving outdated java.io.File code and a custom JMX configuration, allows remote attackers to execute arbitrary code by uploading and accessing a JSP file.
A session fixation flaw was found in the way FormAuthenticator module of Apache Tomcat, an Apache Servlet/JSP Engine, performed authentication requests management in certain circumstances (the most recent authentication request was associated with current user's session). An attacker could use this flaw to inject (and possibly successfully to complete) an authentication request, that would be executed using the credentials of the victim.
Relevant upstream patch: for Apache Tomcat 6.x: http://svn.apache.org/viewvc?view=revision&revision=1417891 for Apache Tomcat 7.x: http://svn.apache.org/viewvc?view=rev&rev=1408044
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.
External references:
http://seclists.org/bugtraq/2016/Feb/147
java/org/apache/coyote/http11/filters/ChunkedInputFilter.java in Apache Tomcat 6.x before 6.0.42, 7.x before 7.0.55, and 8.x before 8.0.9 does not properly handle attempts to continue reading data after an error has occurred, which allows remote attackers to conduct HTTP request smuggling attacks or cause a denial of service (resource consumption) by streaming data with malformed chunked transfer coding.
Apache Tomcat before 6.0.39, 7.x before 7.0.47, and 8.x before 8.0.0-RC3, when an HTTP connector or AJP connector is used, does not properly handle certain inconsistent HTTP request headers, which allows remote attackers to trigger incorrect identification of a request's length and conduct request-smuggling attacks via (1) multiple Content-Length headers or (2) a Content-Length header and a "Transfer-Encoding: chunked" header. NOTE: this vulnerability exists because of an incomplete fix for CVE-2005-2090.
The Mapper component in Apache Tomcat 6.x before 6.0.45, 7.x before 7.0.68, 8.x before 8.0.30, and 9.x before 9.0.0.M2 processes redirects before considering security constraints and Filters, which allows remote attackers to determine the existence of a directory via a URL that lacks a trailing / (slash) character.
It was found that the expression language resolver evaluated expressions within a privileged code section. A malicious web application could use this flaw to bypass security manager protections.
Upstream patches:
http://svn.apache.org/viewvc?view=revision&revision=1644019 http://svn.apache.org/viewvc?view=revision&revision=1645644
External References:
http://tomcat.apache.org/security-6.html#FixedinApacheTomcat6.0.44 http://tomcat.apache.org/security-7.html#FixedinApacheTomcat7.0.59 http://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.0.17
The HTTP Digest Access Authentication implementation in Apache Tomcat 5.5.x before 5.5.36, 6.x before 6.0.36, and 7.x before 7.0.30 caches information about the authenticated user within the session state, which makes it easier for remote attackers to bypass authentication via vectors related to the session ID.
The HTTP Digest Access Authentication implementation in Apache Tomcat 5.5.x before 5.5.36, 6.x before 6.0.36, and 7.x before 7.0.30 does not properly check for stale nonce values in conjunction with enforcement of proper credentials, which makes it easier for remote attackers to bypass intended access restrictions by sniffing the network for valid requests.
The replay-countermeasure functionality in the HTTP Digest Access Authentication implementation in Apache Tomcat 5.5.x before 5.5.36, 6.x before 6.0.36, and 7.x before 7.0.30 tracks cnonce (aka client nonce) values instead of nonce (aka server nonce) and nc (aka nonce-count) values, which makes it easier for remote attackers to bypass intended access restrictions by sniffing the network for valid requests, a different vulnerability than CVE-2011-1184.
Apache Tomcat 6.0.30 through 6.0.33 and 7.x before 7.0.22 does not properly perform certain caching and recycling operations involving request objects, which allows remote attackers to obtain unintended read access to IP address and HTTP header information in opportunistic circumstances by reading TCP data.
A bug in the capabilities code of tomcat5 [1] and tomcat6 [1] was identified in jsvc (the service wrapper for Linux that is part of the Commons Daemon project). jsvc would not drop capabilities, allowing the application to access files and directories owned by the superuser. The vulnerability only occurred when the following conditions were true:
Tomcat is running on Linux jsvc is compiled with libcap -user parameter is used
This affects Tomcat 6.0.30-6.0.32 and is fixed in r1153824 [3] and Tomcat 5.5.32-5.5.33, a proposed patch is available [4], however all these do is update the build files to use the latest Apache Commons Daemon. The real flaw is in the Apache Commons Daemon, and is fixed in upstream 1.0.7 [5]. According to the bug report [6] Commons Daemon 1.0.3-1.0.6 are affected and it is fixed in r11152701 [7].
[1] http://tomcat.apache.org/security-5.html [2] http://tomcat.apache.org/security-6.html [3] http://svn.apache.org/viewvc?view=revision&revision=1153824 [4] http://people.apache.org/~markt/patches/2011-08-12-cve2011-2729-tc5.patch [5] http://mail-archives.apache.org/modmbox/commons-dev/201108.mbox/%3C4E451B2B.9090108@apache.org%3E [6] https://issues.apache.org/jira/browse/DAEMON-214 [7] http://svn.apache.org/viewvc?view=revision&revision=1152701
Apache Tomcat before 5.5.35, 6.x before 6.0.35, and 7.x before 7.0.23 computes hash values for form parameters without restricting the ability to trigger hash collisions predictably, which allows remote attackers to cause a denial of service (CPU consumption) by sending many crafted parameters.
A denial of service flaw was found in the way chunked transfer encoding input filter of Apache Tomcat, an Apache Servlet/JSP Engine, processed CRLF sequences at the end of data chunks in certain circumstances. When the chunked transfer encoding was enabled, a remote attacker could issue a specially-crafted request that, when processed would lead to (limited) denial of service of the Apache Tomcat server.
Relevant upstream patch: for Apache Tomcat 6.x: http://svn.apache.org/viewvc?view=revision&revision=1476592
for Apache Tomcat 7:x: http://svn.apache.org/viewvc?view=rev&rev=1378702 http://svn.apache.org/viewvc?view=rev&rev=1378921
Apache Tomcat 7.0.x before 7.0.17 permits web applications to replace an XML parser used for other web applications, which allows local users to read or modify the (1) web.xml, (2) context.xml, or (3) tld files of arbitrary web applications via a crafted application that is loaded earlier than the target application. NOTE: this vulnerability exists because of a CVE-2009-0783 regression.
org/apache/catalina/core/DefaultInstanceManager.java in Apache Tomcat 7.x before 7.0.22 does not properly restrict ContainerServlets in the Manager application, which allows local users to gain privileges by using an untrusted web application to access the Manager application's functionality.
Apache Tomcat 5.5.x before 5.5.34, 6.x before 6.0.33, and 7.x before 7.0.19, when sendfile is enabled for the HTTP APR or HTTP NIO connector, does not validate certain request attributes, which allows local users to bypass intended file access restrictions or cause a denial of service (infinite loop or JVM crash) by leveraging an untrusted web application.
Apache Tomcat 6.x before 6.0.45, 7.x before 7.0.68, 8.x before 8.0.31, and 9.x before 9.0.0.M2 does not place org.apache.catalina.manager.StatusManagerServlet on the org/apache/catalina/core/RestrictedServlets.properties list, which allows remote authenticated users to bypass intended SecurityManager restrictions and read arbitrary HTTP requests, and consequently discover session ID values, via a crafted web application.
org/apache/catalina/realm/RealmBase.java in Apache Tomcat 6.x before 6.0.36 and 7.x before 7.0.30, when FORM authentication is used, allows remote attackers to bypass security-constraint checks by leveraging a previous setUserPrincipal call and then placing /jsecuritycheck at the end of a URI.
Apache Tomcat 7.0.12 and 7.0.13 processes the first request to a servlet without following security constraints that have been configured through annotations, which allows remote attackers to bypass intended access restrictions via HTTP requests. NOTE: this vulnerability exists because of an incomplete fix for CVE-2011-1088, CVE-2011-1183, and CVE-2011-1419.
Apache Tomcat before 6.0.39, 7.x before 7.0.50, and 8.x before 8.0.0-RC10 allows attackers to obtain "Tomcat internals" information by leveraging the presence of an untrusted web application with a context.xml, web.xml, .jspx, .tagx, or .tld XML document containing an external entity declaration in conjunction with an entity reference, related to an XML External Entity (XXE) issue.
Apache Tomcat before 6.0.39, 7.x before 7.0.50, and 8.x before 8.0.0-RC10 processes chunked transfer coding without properly handling (1) a large total amount of chunked data or (2) whitespace characters in an HTTP header value within a trailer field, which allows remote attackers to cause a denial of service by streaming data. NOTE: this vulnerability exists because of an incomplete fix for CVE-2012-3544.
org/apache/tomcat/util/net/NioEndpoint.java in Apache Tomcat 6.x before 6.0.36 and 7.x before 7.0.28, when the NIO connector is used in conjunction with sendfile and HTTPS, allows remote attackers to cause a denial of service (infinite loop) by terminating the connection during the reading of a response.
An information disclosure flaw was found in the way asynchronous context implementation of Apache Tomcat, an Apache Servlet/JSP Engine, performed request information management in certain circumstances (formerly certain elements of a previous request might have been exposed to the current request). If an application used AsyncListeners that threw RuntimeExceptions, a remote attacker could use this flaw to possibly obtain sensitive information.
Upstream bug report: https://issues.apache.org/bugzilla/showbug.cgi?id=54178
Relevant upstream patch (including testcase): http://svn.apache.org/viewvc?view=rev&rev=1471372
DISPUTED Apache Tomcat 7.x uses world-readable permissions for the log directory and its files, which might allow local users to obtain sensitive information by reading a file. NOTE: One Tomcat distributor has stated "The tomcat log directory does not contain any sensitive information."
Apache Tomcat 5.5.x before 5.5.34, 6.x before 6.0.33, and 7.x before 7.0.17, when the MemoryUserDatabase is used, creates log entries containing passwords upon encountering errors in JMX user creation, which allows local users to obtain sensitive information by reading a log file.