Fixed in Apache Tomcat 6.0.35

Note: The issues below were fixed in Apache Tomcat 6.0.34 but the release vote for the 6.0.34 release candidate did not pass. Therefore, although users must download 6.0.35 to obtain a version that includes a fix for this issue, version 6.0.34 is not included in the list of affected versions.

Important: Information disclosure CVE-2011-3375

For performance reasons, information parsed from a request is often cached in two places: the internal request object and the internal processor object. These objects are not recycled at exactly the same time. When certain errors occur that needed to be added to the access log, the access logging process triggers the re-population of the request object after it has been recycled. However, the request object was not recycled before being used for the next request. That lead to information leakage (e.g. remote IP address, HTTP headers) from the previous request to the next request. The issue was resolved be ensuring that the request and response objects were recycled after being re-populated to generate the necessary access log entries.

This was fixed in revision 1185998.

This was identified by the Tomcat security team on 22 September 2011 and made public on 17 January 2012.

Affects: 6.0.30-6.0.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 1162959.

This was reported publicly on 20th August 2011.

Affects: 6.0.0-6.0.33

Mitigation options:

• Upgrade to Tomcat 6.0.35.
• 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 6.0)
• workers.properties configuration (mod_jk)

Important: Denial of service CVE-2012-0022

Analysis of the recent hash collision vulnerability identified unrelated inefficiencies with Apache Tomcat’s handling of large numbers of parameters and parameter values. These inefficiencies could allow an attacker, via a specially crafted request, to cause large amounts of CPU to be used which in turn could create a denial of service. The issue was addressed by modifying the Tomcat parameter handling code to efficiently process large numbers of parameters and parameter values.

This was fixed in revisions 1200601, 1206324 and 1229027.

This was identified by the Tomcat security team on 21 October 2011 and made public on 17 January 2012.

Affects: 6.0.0-6.0.33