Hash Flaw Allows DoS Attacks

Friday, December 30, 2011 @ 12:12 PM gHale


A common flaw in the implementation of the most popular web programming languages and applications can force servers to use their CPU at full capacity for several minutes, causing a denial-of-service (DoS) condition.

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, said researchers Julian Wälde and Alexander Klink during a presentation at the 28C3 Chaos Communication Congress in Berlin, Germany.

RELATED STORIES
Security Holes Threaten Mobile Phones
SCADA Security Alert: Mobile Workers
Breach: More SCADA System Holes
Compliance Does Not Mean Secure

The issue has been out there since 2003 when Perl and CRuby changed their hash functions to include randomization, but others 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 break fairly easily by using equivalent strings or by launching a meet-in-the-middle attack, according to an advisory 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 a target 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 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.

The easiest way to reduce impact is by limiting the CPU time that a request should take. Also, by limiting the maximal POST size and the number of parameters, the user can mitigate an attack.



Leave a Reply

You must be logged in to post a comment.