BT

Major Denial of Service Vulnerability Affects Most Web Servers

by Jonathan Allen on Jan 03, 2012 |

Security researcher Alexander Klink and Julian Wälde revealed a serious vulnerability that until recently affected the vast majority of web server. The attack only requires a single HTTP request that is specially designed to create hash code collisions in POST form data. When first discovered this attack affected Python, Ruby, PHP, Java, and ASP.NET, but vendors have been working with the researchers to produce patches.

Tomcat updates 7.0.23 and 6.0.35 address this issue by limiting the number of POST form fields to 10,000. The change log says that this is configurable, but no details were provided.

The patch for ASP.NET was released on December 29. The patch will be automatically applied for Windows Azure customers with the default servicing policy. The patch works by limiting the number of POST form fields in a single request to 1,000, which is well below the number needed for a denial of service attack. This value is configurable using the appSettings key “aspnet:MaxHttpCollectionKeys”. Currently this can only be applied site-wide, but there have been requests for page-specific overrides. A fix was also added for related flaws in the JSON input and deserialization logic.

PHP 5.4.0, which is only a release candidate also offers a max_input_vars directive. The release notes do not state what the default value is.

So far every vendor we’ve discussed has addressed the issue at the web server level by limiting the number of fields in a single request. Another option is the use of a randomized hash code formula for strings. Ruby is one such language. .NET does this as well, but only for internal builds. Production releases currently have a set formula, but given the severity of this issue that may change the next time the CLR is updated. For Java it is not quite so easy; the JVM specifies the hash code formula for strings, which means developers may be relying on it to be consistent across all versions.

An update for Oracle Glassfish is supposedly complete, but not yet available. There is no information of the method used to address the issue.

More information about this issue is available on Ars Technica and the Chaos Communication Congress website.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Third option by M Vleth

You(/app server vendors) can always create a specialized string based Map/Dictionary which provides it's own (randomized) hashing algorithm. So basically not relying on the underlying hash code algorithms.

Perl by George Dimitrov

Perl 5.8.1 implemented randomized hash code in 2003.

Re: Third option by George Dimitrov

If the application server implement this, there is a high probability that the application itself (or some third party library) uses standard HashMap/Dictionary to process/store the parameters. This will only move the problem. The best is to change this on a language level as otherwise it is possible to have other similar issues - HTTP headers, cookies, usernames, etc. Unfortunately this is hard because of backward compatibility.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT