See $URL for a more elaborate explanation, I'll update this with more detail later. Specially crafted POST parameters can be used to cause hash table operations with a time complexity of O(n^2), causing a Denial of Service. PHP is working around the issue by limiting the number of input parameters allowed. According to Rasmus Lerdorf, implementing a proper fix will take time. [1] The workaround commits are: http://news.php.net/php.cvs/67294 http://news.php.net/php.cvs/67281 These are scheduled for the next 5.3 and 5.4 releases. [1] Stated in 28C3 talk: http://events.ccc.de/congress/2011/Fahrplan/events/4680.en.html
Until upstream implements the fix, let's bump to a version with the parameter count limit workaround when available.
Secunia advisory says is fixed in git repo https://secunia.com/advisories/47404/
(In reply to comment #2) > Secunia advisory says is fixed in git repo > https://secunia.com/advisories/47404/ Please read my comments. This is a workaround, not a fix.
Core PHP developers and others label max_input_vars as a fix for this issue. However, I agree with Alex that this is more a workaround than a fix. If an application parse an input string and creates a hash table based on the parsed data, the application would still be vulnerable. An example of a vulnerable application is one that accepts JSON data through HTTP POST.
Also worth mentioning that those who have dev-php/suhosin installed will have the same protection as the mentioned workaround through suhosin.request.max_vars.
CVE-2011-4885 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-4885): PHP before 5.3.9 computes hash values for form parameters without restricting the ability to trigger hash collisions predictably, which allows remote attackers to cause a denial of service (CPU consumption) by sending many crafted parameters.
PHP 5.3.9 containing the mentioned workaround has been released.
(In reply to comment #7) > PHP 5.3.9 containing the mentioned workaround has been released. Great, thanks. Shall we call arches to stabilize now via this bug?
I would wait with dealing with this bug until PHP has released a proper fix. 5.3.9 should be stabilised soon anyway due to bug 384301.
(In reply to comment #9) > I would wait with dealing with this bug until PHP has released a proper fix. > > 5.3.9 should be stabilised soon anyway due to bug 384301. Ok, thanks. We'll get the workaround via stabilization in that bug, and hold this open for a more complete fix.
Fixed in 5.3.9
Added to existing glsa request
dev-lang/php-5.3.9 is now stable in the tree. About time we removed, or masked <dev-lang/php-5.3.9 ?
(In reply to comment #13) > dev-lang/php-5.3.9 is now stable in the tree. About time we removed, or masked > <dev-lang/php-5.3.9 ? Great idea! Removed now.
This issue was resolved and addressed in GLSA 201209-03 at http://security.gentoo.org/glsa/glsa-201209-03.xml by GLSA coordinator Sean Amoss (ackle).