Re: Proposal: Add the unordered-containers package and the hashable package to the Haskell Platform

On Wed, Mar 20, 2013 at 11:00 AM, Bardur Arantsson
AFAICT, the hash function needn't be cryptographically secure (though that obviously avoids the issue altogether) -- if there is some determined-at-startup "salt" that's added in to all hashed values then that should provide good enough protection. Obviously this will mean that the hashes won't be repeatable across runs of the same program, but that's usually acceptable for a hash function which isn't used for content identification(*).
(*) For which you should use a cryptographically secure hash anyway.
This is what Python did and unfortunately it's not enough as the salt can easily be recovered if you use a weak hash function. See the SipHash paper.
SipHash is one way to address these kinds of attacks. There are other means as well. For example, many general DoS protection mechanisms (timeouts, IP banning, etc) also work on these kind of attacks.
Timeouts aren't necessarily sufficient -- the application can keep sending data (e.g. form parameter data) and can cause 100% cpu usage for a loooooonng time. After that it can just start over.
But that limits how long the any given request can occupy the CPU for (as we will sever the connection after X seconds.)
IP banning can only happen after the problem occurs.
Not at all. $BIG_WEB_COMPANIES do it on the fly using $SECRET_SMART_SAUCE. Hash flooding is only one of many ways to DoS a server. You can try other things, like building a bot net and trying to flood the connection. Just as sandboxing is a better way to run untrusted software than trying to plug every whole in your code/RTS, generic anti-DoS techniques are usually better than trying to figure out every possible way someone can DoS you. -- Johan

On 03/20/2013 06:14 PM, Johan Tibell wrote:
On Wed, Mar 20, 2013 at 11:00 AM, Bardur Arantsson
wrote: AFAICT, the hash function needn't be cryptographically secure (though that obviously avoids the issue altogether) -- if there is some determined-at-startup "salt" that's added in to all hashed values then that should provide good enough protection. Obviously this will mean that the hashes won't be repeatable across runs of the same program, but that's usually acceptable for a hash function which isn't used for content identification(*).
(*) For which you should use a cryptographically secure hash anyway.
This is what Python did and unfortunately it's not enough as the salt can easily be recovered if you use a weak hash function. See the SipHash paper.
The property behind siphash it is that you won't be able to forge a specific hash (in this instance to put stuff in the same bucket in a hashtable). If you can recover the salt, then you can forge anything you want. Technically any traditional crypto hash would solve the problem too (without salt), as one property is that given a hash it's hard to generate a message, but would kill performance massively of the hashing step, as they are not meant to hash small input.
Not at all. $BIG_WEB_COMPANIES do it on the fly using $SECRET_SMART_SAUCE.
Hash flooding is only one of many ways to DoS a server. You can try other things, like building a bot net and trying to flood the connection. Just as sandboxing is a better way to run untrusted software than trying to plug every whole in your code/RTS, generic anti-DoS techniques are usually better than trying to figure out every possible way someone can DoS you. This is quite untrue that it would solve this problem though, as you can hash flood with perfectly legal network connection, you don't necessarily need to go fast or generate ton of datas or keep a connection open, depending on what your web stuff do.
Also this specific issue is not related to only web framework, it's a generic algorithmic "problem" of hashtables with weak hashing method, as a malicious user can transform a hashtables into a linked list. Potentially if you have anything that is user generated that the code uses as keys (it could be filenames on disk), you could be in this position. -- Vincent

This is quite untrue that it would solve this problem though, Just to clarify, I'm not saying that others protections are bad, just
On 03/22/2013 06:47 AM, Vincent Hanquez wrote: that hash flooding is a pervasive problem not necessarily covered by the other stuffs. The siphash solution is a generic anti-DoS technique as the same level than others. -- Vincent
participants (2)
-
Johan Tibell
-
Vincent Hanquez