A couple of researchers showed how a common flaw in the implementation of the most popular web programming languages and applications can be used to force servers to use their CPU at full capacity for several minutes, causing a denial-of-service (DoS) condition.
Julian Wälde and Alexander Klink made a presentation at the 28C3 Chaos Communication Congress in Berlin, Germany, showing that the way most popular programming languages such as PHP, Java, Apache Tomcat, ASP.NET, Phyton, Plone, Ruby and V8, use hash tables make servers susceptible to DoS attacks.
The issue was known since 2003 when Perl and CRuby changed their hash functions to include randomization, but others seem to have neglected to take the same measures.
Hash tables are data structures that utilize hash functions to map identifying values, or keys, to their associated values. Most of these hash functions can be broken fairly fast by using equivalent strings or by launching a meet-in-the-middle attack, according to the advisory published by n.runs AG.
The first method is plausible because some hash functions have the property that if two strings collide, then hashes having the same substrings at the same position collide as well.
Basically, any website that runs a technology that provides the option to perform a POST request is highly vulnerable to a DoS attack and since the attack is just a POST request, a website can be targeted by using an XSS flaw present on another popular site.
Just to make an idea on how effective these attacks are, Cryptanalysis provides some interesting figures.
Assuming that the processing time for a request is not limited, a Core i7 CPU on a system that uses PHP, can be kept busy for 288 minutes just to process 8 megabytes of POST data. More precisely, you could keep 10,000 such CPU’s busy processing requests by using a 1 gigabit Internet connection.
Some of the vendors rushed to release updates and workarounds for their products. Microsoft will release sometime today an out-of-band security update for ASP.NET and Ruby’s security team have already provided updates for their customers.
The guys from Apache Tomcat also came up with some effective workarounds.
PHP has yet to release an official statement regarding the issue, but in the meantime, users who haven’t heard from their product’s vendor can apply some simple measures to counterattack the problem.
The easiest way to reduce impact is by limiting the CPU time that a request is allowed to take. Also, by limiting the maximal POST size and the number of parameters, an attack can be mitigated.
A video demonstration made by the researchers can be downloaded from here.