Java offers the HashMap and Hashtable classes, which use the String.hashCode() hash function. It is very similar to DJBX33A (instead of 33, it uses the multiplication constant 31 and instead of the start value 5381 it uses 0). Thus it is also vulnerable to an equivalent substring attack. When hashing a string, Java also caches the hash value in the hash attribute, but only if the result is different from zero. Thus, the target value zero is particularly interesting for an attacker as it prevents caching and forces re-hashing. Different web application parse the POST data differently, but the ones tested (Tomcat, Geronima, Jetty, Glassfish) all put the POST form data into either a Hashtable or HashMap object. The maximal POST sizes also differ from server to server, with 2 MB being the most common. Tomcat 6.0.32 server parses a 2 MB string of colliding keys in about 44 minutes of i7 CPU time, so an attacker with about 6 kbit/s can keep one i7 core constantly busy. If the attacker has a Gigabit connection, he can keep about 100.000 i7 cores busy.
I think the previous CVE listed here may be incorrect; I don't see it listed anywhere on https://tomcat.apache.org/security-6.html.
CVE-2012-0022 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-0022): Apache Tomcat 5.5.x before 5.5.35, 6.x before 6.0.34, and 7.x before 7.0.23 uses an inefficient approach for handling parameters, which allows remote attackers to cause a denial of service (CPU consumption) via a request that contains many parameters and parameter values, a different vulnerability than CVE-2011-4858.
CVE-2011-4858 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-4858): 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.
Thanks, folks. GLSA Vote: yes.
GLSA vote: yes. Added to existing GLSA request.
This issue was resolved and addressed in GLSA 201206-24 at http://security.gentoo.org/glsa/glsa-201206-24.xml by GLSA coordinator Tobias Heinlein (keytoaster).
