Apache Tomcat 7.0.0 through 7.0.6 and 6.0.0 through 6.0.30 does not enforce the maxHttpHeaderSize limit for requests involving the NIO HTTP connector, which allows remote attackers to cause a denial of service (OutOfMemoryError) via a crafted request.

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.

The Windows installer for Apache Tomcat 6.0.0 through 6.0.20, 5.5.0 through 5.5.28, and possibly earlier versions uses a blank default password for the administrative user, which allows remote attackers to gain privileges.

The default configuration of Apache Tomcat 6.x does not include the HTTPOnly flag in a Set-Cookie header, which makes it easier for remote attackers to hijack a session via script access to a cookie.

Apache Tomcat 5.5.0 through 5.5.29, 6.0.0 through 6.0.27, and 7.0.0 beta does not properly handle an invalid Transfer-Encoding header, which allows remote attackers to cause a denial of service (application outage) or obtain sensitive information via a crafted header that interferes with "recycling of a buffer."

Multiple security flaws were found in the Apache Tomcat HTTP DIGEST (RFC 2069) Authentication implementation: it was possible to perform session reply attacks, server generated nonce-values were not checked, count of client generated nonce-values were not checked, quality of protection (qop) values were not checked, realms values were not checked, a known, hard-coded string was used as server secret.

References: [1] http://tomcat.apache.org/security-5.html [2] http://tomcat.apache.org/security-6.html [3] http://www.securityfocus.com/archive/1/519818/30/0/threaded

Relevant upstream patches: [4] http://svn.apache.org/viewvc?view=revision&revision=1158180 (for Tomcat 6 version), [5] http://svn.apache.org/viewvc?view=revision&revision=1159309 (for Tomcat 5 version).

The HTTP Digest Access Authentication implementation in Apache Tomcat 5.5.x before 5.5.34, 6.x before 6.0.33, and 7.x before 7.0.12 does not check qop values, which might allow remote attackers to bypass intended integrity-protection requirements via a qop=auth value, a different vulnerability than CVE-2011-1184.

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 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 5.5.32 and 6.0.30 were released [1],[2] to fix, among other things, an XSS vulnerability in the HTML Manager [3]. The HTML Manager displayed unfiltered web application-provided data that could be used to trigger script execution by an administrative user when viewing the Manager pages, such as:

<display-name><script>alert('hi');</script></display-name>

For Tomcat 5.5.x, this was fixed in upstream revision 1057518 [4] and for Tomcat 6.x it was fixed in upstream revision 1057270 [5].

[1] http://tomcat.apache.org/security-5.html#FixedinApacheTomcat5.5.32 [2] http://tomcat.apache.org/security-6.html#FixedinApacheTomcat6.0.30 [3] http://archives.neohapsis.com/archives/fulldisclosure/2011-02/0077.html [4] http://svn.apache.org/viewvc?rev=1057518&view=rev [5] http://svn.apache.org/viewvc?rev=1057270&view=rev

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.

The HTTP Digest Access Authentication implementation in Apache Tomcat 5.5.x before 5.5.34, 6.x before 6.0.33, and 7.x before 7.0.12 does not check realm values, which might allow remote attackers to bypass intended access restrictions by leveraging the availability of a protection space with weaker authentication or authorization requirements, a different vulnerability than CVE-2011-1184.

DigestAuthenticator.java in the HTTP Digest Access Authentication implementation in Apache Tomcat 5.5.x before 5.5.34, 6.x before 6.0.33, and 7.x before 7.0.12 uses Catalina as the hard-coded server secret (aka private key), which makes it easier for remote attackers to bypass cryptographic protection mechanisms by leveraging knowledge of this string, a different vulnerability than CVE-2011-1184.

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.