On Sat, Nov 28, 2015 at 2:00 AM, Pascal KISSIAN <php-mailing-l...@lool.fr> wrote:
> -----Message d'origine----- > De : Nikita Popov [mailto:nikita....@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
