Edit report at https://bugs.php.net/bug.php?id=60655&edit=1

 ID:                 60655
 Updated by:         larue...@php.net
 Reported by:        larue...@php.net
 Summary:            add max_input_vars for json/serialize
 Status:             Open
 Type:               Feature/Change Request
 Package:            *General Issues
 PHP Version:        5.3.9RC4
 Block user comment: N
 Private report:     N

 New Comment:

<laruence> I got you point, and agree in theory, yes, the string hash value 
could 
be the same, does anyone have a method to compute it in real?
<nikic> yes
<laruence> I really doubt that if we can find  so many string keys with the 
same 
hash value to be able launch a attach, and won't reach the max post size


Previous Comments:
------------------------------------------------------------------------
[2012-01-05 14:05:52] larue...@php.net

oh, I got you, thanks.

------------------------------------------------------------------------
[2012-01-05 14:04:50] larue...@php.net

yes, the hash value of string index is the same, but the index = hash_value % 
nTableSize, 

we don't use the hash value as index directly, 

didn't I misunderstand you?

------------------------------------------------------------------------
[2012-01-05 11:53:37] ses...@php.net

You are mistaken to believe that randomizing the TableSize will stop 
predictable 
collisions: This is only true if you try to exploit the problem with numerical 
indicies.

The moment you use alpha numerical keys and produce collisions in the DJB 
hashing function the table size does not matter anymore, because the return 
value of the hash function is the same.

------------------------------------------------------------------------
[2012-01-05 11:29:15] larue...@php.net

sorry, didn't get your point?  
the collision can not be predicatible any more, why this patch doesn't solve 
the 
problem?

------------------------------------------------------------------------
[2012-01-05 11:24:44] ses...@php.net

Your patch does not fix the problem.

It will make the first X hashtable grow operations random.
But the moment you already inserte 65536 entries the HashTable is now big 
enough 
to launch the attack.

Maybe your test script already breaks your patch the moment you try to insert 
2^17 entries.

Otherwise the attack script might need some tweaking. Anyway, your patch will 
not solve the problem.

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=60655


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1

Reply via email to