Hi:
so here is the problem, the number index collision can be fixed by
this idea (increase table size with a random delta).
now we need add the random number into DJB hash, and I am not good at math,
so Calling for help, and the random number will be stored in a
process global variable like: PHPAPI int zend_hash_random_number.
and the reason for use a process global variable are:
1. this would break the zend hash cache
2. no abi backward break ( zend_hash_func)
3. simplify ZTS protection..
any help will be appreciated.
thanks
On Thu, Jan 5, 2012 at 10:21 PM, Laruence <larue...@php.net> wrote:
> Hi,
> thanks to sesser, he point out that this won't work for string keys,
>
> so, I guess, we should change the hash logic in the mean time.. I
> will keep trying.
>
> thanks
>
> On Thu, Jan 5, 2012 at 9:12 PM, Etienne Kneuss <col...@php.net> wrote:
>> Hi,
>>
>> On Thu, Jan 5, 2012 at 13:05, Nikita Popov <nikita....@googlemail.com> wrote:
>>> On Thu, Jan 5, 2012 at 9:53 AM, Laruence <larue...@php.net> wrote:
>>>> Hi:
>>>> the origin thread is too long, so I open a new thread for this.
>>>>
>>>> I have made another patch try to fix this issue.
>>>>
>>>> the key point is, randomizing the table size(tableMask).
>>>>
>>>> instead of double the the table size in zend_hash_do_resize, I
>>>> increase the table size with a random delta ( the value now is just a
>>>> try, we can change it to a more appropriate value),
>>>> that is: new_table_size = old_table_size * 2 + random_num.
>>>>
>>>> then, the collision can not be predicatible, which fix the
>>>> problem, and also fixed the issue in json/soap/serialize etc.
>>>>
>>>> here is the patch(draft now):
>>>> https://bugs.php.net/patch-display.php?bug_id=60655&patch=rand_hash_resize.patch&revision=latest
>>>>
>>>> after this fix , may slow down the php, but compared to the
>>>> security threat I thinks the cost could be ignored.
>>>>
>>>> for the test script list in
>>>> http://nikic.github.com/2011/12/28/Supercolliding-a-PHP-array.html:
>>>>
>>>> *before patched:
>>>> Inserting 65536 evil elements took 162.65940284729 seconds
>>>> Inserting 65536 good elements took 0.075557947158813 seconds
>>>>
>>>> *after patched:
>>>> Inserting 65536 evil elements took 0.074128866195679 seconds
>>>> Inserting 65536 good elements took 0.091044902801514 seconds
>>>>
>>>> what do you think ?
>>>
>>> At least one problem with your patch is that it uses crypto safe
>>> random numbers. The problem with that is that the very frequent random
>>> number fetches could deplete the entropy pool and thus make
>>> /dev/urandom (and probably the Windows RNG too) block. So you would
>>> again have a DOS vulnerability (just create many small arrays with 16
>>> elements so they get resized a few times). Additionally this could
>>> also impose a security threat to other application that rely on the
>>> entropy source.
>>
>> In essence there should only be the need for one random number per
>> request, so it should be fine in that regard.
>>
>>>
>>> Nikita
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>
>>
>>
>> --
>> Etienne Kneuss
>> http://www.colder.ch
>
>
>
> --
> Laruence Xinchen Hui
> http://www.laruence.com/
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
