5 ms·

Effective DoS attacks against Web Application Platforms

42 points by llambda 15y ago

pavelkaroukin 15y ago
It is funny how this site was DDoSed by getting to the first page on HN :) http://webcache.googleusercontent.com/search?q=cache:D8sBZ4-aAVYJ:cryptanalysis.eu/blog/2011/12/28/effective-dos-attacks-against-web-application-plattforms-hashdos http://webcache.googleusercontent.com/search?q=cache:D8sBZ4-...
evilmanic 15y ago
As the site appears down: http://webcache.googleusercontent.com/search?q=cache:D8sBZ4-aAVYJ:cryptanalysis.eu/blog/2011/12/28/effective-dos-attacks-against-web-application-plattforms-hashdos/+hashdos&cd=1&hl=en&ct=clnk&gl=uk 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.
- thaumaturgy 15y ago
  "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.
- DasIch 15y ago
  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.
vineetdhanawat 15y ago
Site is still down. Even the cache is not opening for me! :(
ifeatu 15y ago
Better link for info on the vulnerability: http://www.nruns.com/_downloads/advisory28122011.pdf http://www.nruns.com/_downloads/advisory28122011.pdf
DasIch 15y ago
This is the talk they gave on 28C3: http://www.youtube.com/28c3#p/u/24/_EEhviEO1Vo http://www.youtube.com/28c3#p/u/24/_EEhviEO1Vo
- ivank 15y ago
  Fixed video: http://www.youtube.com/watch?v=R2Cq3CLI6H8 http://www.youtube.com/watch?v=R2Cq3CLI6H8
atambo 15y ago
jruby 1.6.5.1 was released to fix this: http://jruby.org/2011/12/27/jruby-1-6-5-1.html http://jruby.org/2011/12/27/jruby-1-6-5-1.html
willvarfar 15y ago
Solution: How to make hash tables impervious to collision attacks http://news.ycombinator.com/item?id=3401773 http://news.ycombinator.com/item?id=3401773
- mjb 15y ago
  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.
  - willvarfar 15y ago
    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.
atambo 15y ago
You can see a list of vulnerable versions of languages and fixes here: http://www.ocert.org/advisories/ocert-2011-003.html http://www.ocert.org/advisories/ocert-2011-003.html
ivank 15y ago
I wrote a `securedict` to work around this problem in Python: https://github.com/ludios/Securetypes https://github.com/ludios/Securetypes This problem is not new, see: http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003/ http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec... http://mail.python.org/pipermail/python-dev/2003-May/035874.html http://mail.python.org/pipermail/python-dev/2003-May/035874....
pdw 15y ago
This is quite surprising to me, this problem was solved long ago in Perl: http://perldoc.perl.org/perlsec.html#Algorithmic-Complexity-Attacks http://perldoc.perl.org/perlsec.html#Algorithmic-Complexity-...
0x0 15y ago
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?
rmoriz 15y ago
you can find the video now at http://www.youtube.com/watch?v=R2Cq3CLI6H8 http://www.youtube.com/watch?v=R2Cq3CLI6H8 (release version)
jness 15y ago
Microsoft ASP.NET fix coming tomorrow morning at 10am. http://technet.microsoft.com/en-us/security/bulletin/ms11-dec http://technet.microsoft.com/en-us/security/bulletin/ms11-de...

42 points by llambda 15y ago

It is funny how this site was DDoSed by getting to the first page on HN :) http://webcache.googleusercontent.com/search?q=cache:D8sBZ4-aAVYJ:cryptanalysis.eu/blog/2011/12/28/effective-dos-attacks-against-web-application-plattforms-hashdos http://webcache.googleusercontent.com/search?q=cache:D8sBZ4-...

evilmanic 15y ago

As the site appears down: http://webcache.googleusercontent.com/search?q=cache:D8sBZ4-aAVYJ:cryptanalysis.eu/blog/2011/12/28/effective-dos-attacks-against-web-application-plattforms-hashdos/+hashdos&cd=1&hl=en&ct=clnk&gl=uk 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.

thaumaturgy 15y ago
"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.
DasIch 15y ago
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.

vineetdhanawat 15y ago

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

ifeatu 15y ago

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

DasIch 15y ago

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

ivank 15y ago
Fixed video: http://www.youtube.com/watch?v=R2Cq3CLI6H8 http://www.youtube.com/watch?v=R2Cq3CLI6H8

atambo 15y ago

jruby 1.6.5.1 was released to fix this: http://jruby.org/2011/12/27/jruby-1-6-5-1.html http://jruby.org/2011/12/27/jruby-1-6-5-1.html

willvarfar 15y ago

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

mjb 15y ago
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.
- willvarfar 15y ago
  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.

atambo 15y ago

You can see a list of vulnerable versions of languages and fixes here: http://www.ocert.org/advisories/ocert-2011-003.html http://www.ocert.org/advisories/ocert-2011-003.html

ivank 15y ago

I wrote a `securedict` to work around this problem in Python: https://github.com/ludios/Securetypes https://github.com/ludios/Securetypes This problem is not new, see: http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003/ http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec... http://mail.python.org/pipermail/python-dev/2003-May/035874.html http://mail.python.org/pipermail/python-dev/2003-May/035874....

pdw 15y ago

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

0x0 15y ago

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?

rmoriz 15y ago

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

jness 15y ago

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