Dear Pierre and others, > I'd strongly suggest to release 5.3.9 (RC5 has been tested now) final > this week using the max_input_vars fix, with the modification from > Laruence (but with a larger limit). Laruence addition also fixes > serialize or json, which are parts that need this fix as well as it is > impossible to valid a string manually (length check only is not enough > or cannot work in all cases).
Why do you advocate a patch from Laruence that randomizes the size of the HashTable, which does not fix the HashDOS security problem at all? It seems that the majority of people working on this HashDOS stuff do not understand the actual mathematical problem and try to exploit it by using numerical indices. In case of numerical indices a collision is trivial: 0x00010000, 0x00020000,0x00030000, … 0xFFFF0000 will all collide because n mod 2^x is always 0 for x<=16. This is however just the cheap way to cause HashTable collisions in PHP. The actual HashDOS exploit the nruns guys were talking about *DOES NOT* involve numerical indices at all. The nruns guys are speaking about collisions in the DJB hash function, which is used for alpha numerical indices. This cannot be fixed by random HashTable size increments. Random HashTable size increments will only lead to tricky debugging situations, because due to the randomness the PHP memory layout/usage for the same script will be totally different with each run. Just one of the possible consequences: the same script, running on the same server, called 2 times with the same parameters can e.g. cause memory limit violations in totally different places. Or sometimes does not violate the memory limit at all. And this all ignores the fact that the patch by Laruence is broken and performs dangerous operations on the size field that could introduce further problems. *** The only way to fix the HashTable implementation is by using a randomized HashFunction (not a randomized HashTable) *** *** And of course resource limits are always a good addition to protect against this and future different vulnerabilities. *** Regards, Stefan Esser
signature.asc
Description: Message signed with OpenPGP using GPGMail
