Effective DoS attacks against Web Application Platforms | Hacker News Reader

Effective DoS attacks against Web Application Platforms

cryptanalysis.eu

42 pointsllambda18 comments

Open articleView on HN

It is funny how this site was DDoSed by getting to the first page on HN :)

http://webcache.googleusercontent.com/search?q=cache:D8sBZ4-...

I wrote a `securedict` to work around this problem in Python: https://github.com/ludios/Securetypes

This problem is not new, see:

http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec...

http://mail.python.org/pipermail/python-dev/2003-May/035874....

Better link for info on the vulnerability: http://www.nruns.com/_downloads/advisory28122011.pdf

This is the talk they gave on 28C3: http://www.youtube.com/28c3#p/u/24/_EEhviEO1Vo

Fixed video: http://www.youtube.com/watch?v=R2Cq3CLI6H8

This is quite surprising to me, this problem was solved long ago in Perl: http://perldoc.perl.org/perlsec.html#Algorithmic-Complexity-...

You can see a list of vulnerable versions of languages and fixes here:

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

Microsoft ASP.NET fix coming tomorrow morning at 10am. http://technet.microsoft.com/en-us/security/bulletin/ms11-de...

Solution: How to make hash tables impervious to collision attacks http://news.ycombinator.com/item?id=3401773

As is mentioned in the article, using cryptographically secure hash functions doesn't help - unless you also provide some salt or otherwise randomize the function in some way. On the other hand, if you are already randomizing the function in some way, using a cryptographically secure hash is unlikely to help - as long as the salt/seed is has a range substantially larger than the table size.

Using a balanced tree in place of a list in a separately chained hash table is possible - but adds much complexity and reduced average-case performance to solve a problem that seems better to solve in a different way. Dynamic perfect hashing works too, but opens you up to a new memory exhaustion attack.

A combination of limiting header size and adding a seed to the hash function, as mentioned in the article, seems like the right way. Limiting header sizes and counts is something that servers should be doing anyways, and seeding the hash function seems to close this hole quite neatly.

until the attacker picks on your JSON parser or such, of course.

Adding a balanced tree does not touch on average-case performance in any meaningful way, which is why I'm advocating it.

Everyone is using simple hashes for hash tables in order to get very good average-case performance.

If you keep that fast hash function, and only go to a tree when getting pathological input, you'll be impervious. That was my meaning.

Wasn't this covered back in the 2003-2004 timeframe? I specifically seem to remember seeing some sort of PHP advisory, but I can't track it down now.

What's new this time?

As the site appears down: http://webcache.googleusercontent.com/search?q=cache:D8sBZ4-...

You mean to say, that if you've configured PHP in a poor way, (max post size, max execution time not appropriately tuned ) then you are open to a DoS? -- If you've configured it that badly, then this is probably the least of your worries.

"Configure it badly" is simplistic. If you have a webmail application, how do you allow your users to upload reasonable email attachments (say 10MB for most providers) while not exposing yourself to this particular problem?

The max_input_vars parameter was a new one for me.

The issue is not limited to PHP. Node.js/V8, CPython, Java, CRuby 1.8 and quite a lot of other implementations have this problem.

Furthermore this is a problem you will encounter in every case in which the keys you populate a hash table with come from an untrusted source.

jruby 1.6.5.1 was released to fix this:

http://jruby.org/2011/12/27/jruby-1-6-5-1.html

you can find the video now at http://www.youtube.com/watch?v=R2Cq3CLI6H8 (release version)

Site is still down. Even the cache is not opening for me! :(

Reply on news.ycombinator.com