Security alert - Remote denial of service vulnerability affects all versions of Apache Tomcat
July 9, 2010 - Apache released a security update today warning users of a newly discovered flaw in the Tomcat code that could potentially be exploited by malicious users to execute a Remote Denial of Service attack against a vulnerable Tomcat instance. A patch for the issue has already been created, and is available as a standalone fix or incorporated into new versions of all actively supported Tomcat branches. The flaw was discovered and reported by Steve Jones, a Tomcat community member.
Who is vulnerable
The security hole affects all stable versions of Apache Tomcat less than the most recent versions, as well as the Tomcat 7 beta:
Apache Tomcat 5.5.0 through 5.5.29
Apache Tomcat 6.0.0 through 6.0.27
Apache Tomcat 7.0.0 Beta
How the exploit works
Flaws in Tomcat's handling of 'Transfer-Encoding' headers were found to be preventing a buffer from recycling. This flaw could potentially be intentionally triggered by a malicious remote user to cause failure of subsequent requests and possible information leaks. For more detailed information, click here to visit the CVE entry.
Fixing the issue
Patches have already been developed for all versions of Tomcat, and incorporated into new versions of each supported branch. Follow the instructions below to secure your server:
Using Tomcat 5.5.x
Upgrade to Tomcat 5.5.30 - Click Here To Download
…or apply the standalone patch: http://svn.apache.org/viewvc?view=revision&revision=959428
Using Tomcat 6.0.x
Upgrade to Tomcat 6.0.28 - Click Here To Download
…or apply the standalone patch: http://svn.apache.org/viewvc?view=revision&revision=958977
Testing Tomcat 7.0.x Beta
Tomcat 7.0.1 is not yet available.
To secure your servers, apply the standalone patch: http://svn.apache.org/viewvc?view=revision&revision=958911
…and upgrade to Tomcat 7.0.1 as soon as it is released.
Unable To upgrade:
Users that are currently unable to upgrade to a newer version of Tomcat can secure their Tomcat instances temporarily by running them behind a reverse proxy with the ability to reject invalid Transfer-Encoding values. If you are unsure as to whether or not your proxy supports this feature (i.e. Apache httpd 2.2.x).