Press "Enter" to skip to content

Denial-of-Service Attacks on Various Languages via Constructed Hash Collisions

Last week, dmitry suddenly introduced a new configuration directive right before the 5.4 release:

Added max_input_vars directive to prevent attacks based on hash collisions

The attack this prevents is the "denial-of-service across multiple implementations via hash algorithm collision" (multiple implementations denial-of-service via hash algorithm collision).
The attack principle is simple. Currently many languages use a hash table to store k-v data, including the common user-derived POST data. An attacker can construct a request accompanied by a large number of specially crafted "k" values (tailored to each language's hash algorithm), causing the hash table that stores POST data under the language's hood to degrade into a linked list due to "collisions".

In this way, if the data volume is large enough, the language will consume a huge amount of CPU during computation, lookup and insertion, thereby achieving a denial-of-service attack.
PHP 5.4 avoids being affected by this kind of attack by adding a limit:

  - max_input_vars - specifies how many GET/POST/COOKIE input variables may be
    accepted. default value 1000.

Currently known affected languages and versions::

Java, all versions

JRuby <= 1.6.5

PHP <= 5.3.8, <= 5.4.0RC3

Python, all versions

Rubinius, all versions

Ruby <= 1.8.7-p356

Apache Geronimo, all versions

Apache Tomcat <= 5.5.34, <= 6.0.34, <= 7.0.22

Oracle Glassfish <= 3.1.1

Jetty, all versions

Plone, all versions

Rack, all versions

V8 JavaScript Engine, all versions

Languages not affected, or fixed versions::

PHP >= 5.3.9, >= 5.4.0RC4

JRuby >= 1.6.5.1

Ruby >= 1.8.7-p357, 1.9.x

Apache Tomcat >= 5.5.35, >= 6.0.35, >= 7.0.23

Oracle Glassfish, N/A (Oracle reports that the issue is fixed in the main codeline and scheduled for a future CPU)

CVE: CVE-2011-4885 (PHP), CVE-2011-4461 (Jetty), CVE-2011-4838 (JRuby), CVE-2011-4462 (Plone), CVE-2011-4815 (Ruby)

Original: http://www.ocert.org/advisories/ocert-2011-003.html

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.