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.

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

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.

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?

oh, I got you, thanks.

<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

It is not "a theory", The whole disclosure from n-runs was about colliding the DJB 
hash function with alpha numerical keys.

sesser, I am not good at algorithm, so if you can help me, I will appreciate.

just a guess, what about change the zend_hash_func, add some new seed like:

register ulong hash = 5381 + nKeyLength;

thanks

BTW a simple approach to cause 65536 alpha numerical collisions would use most 
probably less than 2MB of POST payload. And this is the NOT mathematically 
optimized version.

laruence: nothing against you, but fixing the hash table thing is not a simple 
easy fix. It must be done by someone who understands the mathematical problem of 
hash collisions and who understands the impact of making changes to a hash 
function.

Just changing some constants in the algorithm will not improve the situation. 
The opposite can be the case. By changing some constants it could be possible to 
destroy the distribution of collisions and suddenly some values collide more 
often than others.

So please do not try to fix a problem that must be solved by someone with the 
mathematical background knowledge.

sesser, yes, you are right, a constant can not fix this problem, only make it more 
diffcult to find the special keys..

As the authors say in the video the Perl solved this in 2003. They fixed it by randomizing hash seed. Probably for each "hash".
You can look this video for more details:
http://www.youtube.com/watch?v=R2Cq3CLI6H8&feature=channel_video_title