Fixed in Apache Tomcat 5.5.34

Moderate: Multiple weaknesses in HTTP DIGEST authentication CVE-2011-1184

Note: Mitre elected to break this issue down into multiple issues and have allocated the following additional references to parts of this issue: CVE-2011-5062, CVE-2011-5063 and CVE-2011-5064. The Apache Tomcat security team will continue to treat this as a single issue using the reference CVE-2011-1184.

The implementation of HTTP DIGEST authentication was discovered to have several weaknesses:

• replay attacks were permitted
• server nonces were not checked
• client nonce counts were not checked
• qop values were not checked
• realm values were not checked
• the server secret was hard-coded to a known string

The result of these weaknesses is that DIGEST authentication was only as secure as BASIC authentication.

This was fixed in revision 1159309.

This was identified by the Tomcat security team on 16 March 2011 and made public on 26 September 2011.

Affects: 5.5.0-5.5.33

Low: Information disclosure CVE-2011-2204

When using the MemoryUserDatabase (based on tomcat-users.xml) and creating users via JMX, an exception during the user creation process may trigger an error message in the JMX client that includes the user’s password. This error message is also written to the Tomcat logs. User passwords are visible to administrators with JMX access and/or administrators with read access to the tomcat-users.xml file. Users that do not have these permissions but are able to read log files may be able to discover a user’s password.

This was fixed in revision 1140072.

This was identified by Polina Genova on 14 June 2011 and made public on 27 June 2011.

Affects: 5.5.0-5.5.33

Low: Information disclosure CVE-2011-2526

Tomcat provides support for sendfile with the HTTP APR connector. sendfile is used automatically for content served via the DefaultServlet and deployed web applications may use it directly via setting request attributes. These request attributes were not validated. When running under a security manager, this lack of validation allowed a malicious web application to do one or more of the following that would normally be prevented by a security manager:

• return files to users that the security manager should make inaccessible
• terminate (via a crash) the JVM

Additionally, these vulnerabilities only occur when all of the following are true:

• untrusted web applications are being used
• the SecurityManager is used to limit the untrusted web applications
• the HTTP APR connector is used
• sendfile is enabled for the connector (this is the default)

This was fixed in revision 1158244.

This was identified by the Tomcat security team on 7 July 2011 and made public on 13 July 2011.

Affects: 5.5.0-5.5.33

Important: Information disclosure CVE-2011-2729

Due to a bug in the capabilities code, jsvc (the service wrapper for Linux that is part of the Commons Daemon project) does not drop capabilities allowing the application to access files and directories owned by superuser. This vulnerability only occurs when all of the following are true:

• Tomcat is running on a Linux operating system
• jsvc was compiled with libcap
• -user parameter is used

Affected Tomcat versions shipped with source files for jsvc that included this vulnerability.

This was fixed in revision 1159346.

This was identified by Wilfried Weissmann on 20 July 2011 and made public on 12 August 2011.

Affects: 5.5.32-5.5.33

Important: Authentication bypass and information disclosure CVE-2011-3190

Apache Tomcat supports the AJP protocol which is used with reverse proxies to pass requests and associated data about the request from the reverse proxy to Tomcat. The AJP protocol is designed so that when a request includes a request body, an unsolicited AJP message is sent to Tomcat that includes the first part (or possibly all) of the request body. In certain circumstances, Tomcat did not process this message as a request body but as a new request. This permitted an attacker to have full control over the AJP message permitting authentication bypass and information disclosure. This vulnerability only occurs when all of the following are true:

• The org.apache.jk.server.JkCoyoteHandler AJP connector is not used
• POST requests are accepted
• The request body is not processed

This was fixed in revision 1162960.

This was reported publicly on 20th August 2011.

Affects: 5.5.0-5.5.33

Mitigation options:

• Upgrade to Tomcat 5.5.34.
• Apply the appropriate patch.
• Configure both Tomcat and the reverse proxy to use a shared secret.
  (It is “request.secret” attribute in AJP <Connector>, “worker.workername.secret” directive for mod_jk. The mod_proxy_ajp module currently does not support shared secrets).
• Use the org.apache.jk.server.JkCoyoteHandler (BIO) AJP connector implementation.
  (It is automatically selected if you do not have Tomcat-Native library installed. It can be also selected explicitly: <Connector protocol=“org.apache.jk.server.JkCoyoteHandler”>).

References:

• AJP Connector documentation (Tomcat 5.5)
• workers.properties configuration (mod_jk)