De : Nikita Popov [mailto:nikita....@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-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
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
