RE: HashDos protection

De : Nikita Popov [mailto:nikita.ppv@gmail.com] Envoyé : samedi 28 novembre 2015 11:35 À : Pascal KISSIAN Cc : PHP internals Objet : Re: HashDos protection On Sat, Nov 28, 2015 at 2:00 AM, Pascal KISSIAN <php-mailing-list@lool.fr> wrote: -----Message d'origine----- De : Nikita Popov [mailto:nikita.ppv@gmail.com] Envoyé : jeudi 26 novembre 2015 18:25 À : PHP internals; Anatol Belski; Remi Collet Objet : HashDos protection >>>Hi internals! >>>his mail turned out to be rather long, so I'll start with a TL;DR: >>>To fix the HashDos vulnerability for *all* cases (rather than just GET/POST parsing), I >>>propose to introduce collision counting during hashtable insertion operations. This will throw a >>>fatal error if the number of collisions during an insertion operation exceed a certain threshold. >>>In PHP 5.3.9 a partial fix for the HashDos vulnerability was introduced in the form of >>>max_input_vars. >>Hi everybody... >>I am very new to this mailing list, and I do not know If my thinking about this problem is >>good, but to my opinion, this kind of attack is based on the fact that the hacker knows in advance >>how to compute the hash value in order to generate collision. >>If a random salt was added in the _zend_array struct (at a cost of the salt size 4 bytes? >>for each hash table), >>Then if the hash computation takes that salt into account ( add ht parameter to each >>function that calculates the hash) >>It would be impossible to predict the hash of a value. >>So impossible to perform such kind of attack... >>What do you think about that ? >>Perhaps if you do not want to increase the size of the the _zend_array struct, perhaps a >>random salt initialized at the init of a php program (the same for all hash >>tables, that >>changes at each run) could be enough! >This is what variant 2 (Switch hashtables to a keyed cryptographic hash like SipHash) describes, >using a global per-pool key. >Nikita Sorry Nikita, I didn’t fully read your 1st message because it was speaking on changing hash algo…, and I’ve been a bit lazy on that… However, I only have thought about a minor change introducing a salt. In the zend_inline_hash_func , hash is initialized with Z_UL(5381) … what about just adding a salt value to this number, this would not make any performance issue. For hashing integers, why just not adding a salt value also… and no performance issue…. For storing the salt, if you choose to have one different random value for each hash table, it would not be a problem for arrays living in opcache SHM… (and hoping that no performance, nor memory issue arise increasing a bit the size of the hash table) pk