[rufibarbatus]

> PHP already landed a change (which will ship with PHP 5.3.9) which will add a max_input_vars ini setting which defaults to 1000. This setting determines the maximum number of POST/GET variables that are accepted, so now only a maximum of 1000 collisions can be created.

Wait, where did we establish that less user input = less array insertions?

[pavel_lishin]

Well, the point of that change was to prevent a hostile user from DoSing your server with malicious GET/POST requests.

I imagine it would actually be fairly difficult to accidentally recreate this issue, or let it slip through testing. No amount of patches in the world will protect you from idiots with access to your codebase

[1880]

Maybe they're referring to the $_POST array? You can't fix that in your app code.

[subwindow]

I think the most obvious exploit path is using thousands of query parameters, which are inserted into an "array" in PHP.

An ini setting seems like a terrible and incomplete fix to the problem.

[maratd]

> An ini setting seems like a terrible and incomplete fix to the problem.

Why? It solves the problem entirely.

[subwindow]

It only solves the exploit path, not the vulnerability.

The true issue is that their hashing algorithm sucks. Any patch that doesn't fix the hashing algorithm is a band-aid and not a true fix.

[nikic]

It is somewhat risky to fundamentally change the hashing algorithm late in the release cycle (RC4). It is bound to cause problems. The ini-Option prevents the obvious threat without doing deep changes to the core.