So. There is a know denial of service issue caused by the specific hashing algorithm that everybody seems to use.
Everybody fixes it by randomizing tables used by said algorithm at initialization time.
PHP "fixes" it by not touching the hash algorithm and adding a max_input_vars configuration setting, thereby reducing the functionality while not really fixing the underlying security issue. This also means that if max_input_vars is set reasonably high (or has to be set as such), an attacker can still do the exact same DOS attack - albeit using more concurrent connections.
I can't even believe that the desire to keep backwards compatibility at all costs is a valid reason for a decision like this: Older versions supported an arbitrary amount of input fields, the current version does not, so this is a clear BC break.
Especially when considering that PHP is getting better with their release process (i.e. not having 100s of failing tests so that the 101st that fails would be missed), I really think this half-assed solution is way too cautious - especially as other projects had the exact same issue and solved it more correctly - without causing (apparent) regressions so far.
PHP could just - again - copy their updated algorithm.
Not endemic to PHP, of course, as it seems MSFT took the same approach with a recent ASP.NET security update. The workaround described in their KB (http://support.microsoft.com/kb/2661403) is to add a similar configuration override and they've set the limit arbitrarily at 1000 form keys. Which vendors did not dodge the hash algorithm problem and what's the updated algorithm you're referencing? Who's doing this right?
Ruby 1.9 was already randomizing the hashes whereas this current rediscovery of the problem caused them to fix it by randomizing in 1.8 too. Same goes for Python.
By randomizing I mean randomizing that value for h for the lifetime you need your hashes to be consistent (until the script ends in PHP)
While you are still vulnerable to attackers who know what that random initial value is, finding that by just randomly trying to create the collisions is impractical and easily detectable.
If you have open-source projects on github, you should really checkout travis (http://travis-ci.org/). Travis is also able to run tests in different php environments and can be hooked into github to tests whenever you commit! :)
Indeed! I have been quite pleasantly surprised lately with the more constructive discussions around PHP related items. The LOLPHP posts have been at a minimum (I don't mind genuine criticism).
Everybody fixes it by randomizing tables used by said algorithm at initialization time.
PHP "fixes" it by not touching the hash algorithm and adding a max_input_vars configuration setting, thereby reducing the functionality while not really fixing the underlying security issue. This also means that if max_input_vars is set reasonably high (or has to be set as such), an attacker can still do the exact same DOS attack - albeit using more concurrent connections.
I can't even believe that the desire to keep backwards compatibility at all costs is a valid reason for a decision like this: Older versions supported an arbitrary amount of input fields, the current version does not, so this is a clear BC break.
Especially when considering that PHP is getting better with their release process (i.e. not having 100s of failing tests so that the 101st that fails would be missed), I really think this half-assed solution is way too cautious - especially as other projects had the exact same issue and solved it more correctly - without causing (apparent) regressions so far.
PHP could just - again - copy their updated algorithm.
(related discussion on their mailing list: http://news.php.net/php.internals/57291)