Earlier this week at the 28C3 security conference in Berlin researchers presented on a denial of service (DOS) technique that several web application platforms (PHP, ASP.NET, Node.js, Tomcat, Java's HashMap/Hashtable etc) are vulnerable to, known as hashdos.
The exploit takes advantage of hash collisions in the internal implementation of hashtables / hashmaps (think CFML struct). When two keys are hashed and result in the same hash code a collision occurs, and additional processing must take place to store or retrieve the item. Most application servers store request input variable (eg form, url scopes) in such a data structure. If you can construct a request with variable names that all have the same internal hashcode, the request goes from taking less than a second to process to several minutes.
As you can imagine this can cause a server to crawl/crash pretty quickly with a relatively small payload. Microsoft has released an out of band security patch for ASP.NET already. Tomcat has provided a work around in versions 7.0.23 or 6.0.35 and up.
The typical patch / workaround for this issue is to limit the number of input request variables, ASP.NET defaults this limit to 1000, tomcat defaults to 10,000.
Update: - Adobe has released a security hotfix to address this issue on ColdFusion 8 and 9. If you are running CF 6 or 7 you may still be vulnerable to this but Adobe no longer produces security hotfixes for these versions (upgrade to CF 8 or above).
To learn more about the mitigation that Adobe ColdFusion has put into place for HashDOS you can read my follow up post: Understanding HashDos and postParameterLimit.
Comments
We have released a security hot-fix addressing this issue for ColdFusion 9.0.1 and earlier. More details are http://shilpikhariwal.com/2012/03/security-hot-fix-for-coldfusion-march.html
Hey, Pete. Have you heard of any new info at all on this matter, in the 8 years since? Just curious to tap your brain and most substantial experience, for everyone's sake. :-) Thanks for this and all you do.
Hi Charlie - no there is not any new info on this issue. The mitigation that has been put in place is to just limit the number of keys possible in the hash table. That is what the Maximum number of POST request parameters setting in CF admin does. There is a bit more info on a subsequent post here: https://www.petefreitag.com/item/808.cfm
Thanks, Pete. And sorry, I should have added that I'd already seen that other post. I just meant if there was perhaps new info on whether a) this setting is a protection against only a DOS attack (which is not as disconcerting as if it was somehow now known to be a door to some sort of break-in), or whether b) it may have been that either Tomcat or .NET may have been known to have lower their limits. It always surprised me that if those chose 10,000 and 1,000, then why did Adobe go so low as to choose only 200, which people (especially with older apps) trip over all the time. But if you'd say there really is no new info you're aware of about these things since then, no worries. I just wanted to check if perhaps you did, and for the sake of others who may come across this post in the future.
Correct, a denial of service is the only attack vector that I am aware of that pertains to the setting. I am not sure as to the reason Adobe choose the default limit, but it could be that the Hash table implementation used by the form (and other) scopes is slower WRT collisions than the one used by .NET or by Tomcat so it needed to be set lower. It's not necessarily an apples to apples comparison as they could have chosen different algorithms. The maxParameterCount setting in Tomcat still defaults to 10,000 in Tomcat 9. As I mention in the other post with 50,000 parameters you can craft a request that might take the server 30 minutes to process. So using those numbers if you had 10,000 parameters it might still take 6 minutes (though probably a bit less, since it is exponential) to process the request (and it would not timeout). This was several years ago, so the numbers may differ now and of course depend on the hardware used.
Wonderful. Thanks for the clarifications, Pete.