5 ms·
PHP 5.3.10 release delivers a critical security fix
- purephase 15y agoIt's already hit IUS, which is good. It just sucks since I just upgraded all of our development servers to 5.3.9 and we were just completing our tests to roll to production. C'est la vie.
- wildmXranat 15y agoFound this related article: http://thexploit.com/sec/critical-php-remote-vulnerability-introduced-in-fix-for-php-hashtable-collision-dos/ http://thexploit.com/sec/critical-php-remote-vulnerability-i...
- NiekvdMaas 15y agoLink to a PoC in JavaScript - anybody tested this? https://gist.github.com/1725489 https://gist.github.com/1725489
- ck2 15y agoWork around this by using suhosin to restrict the variable count even more than PHP's limit. Also your get/post size limit should be restricted anyway, the defaults are far too high.
- ars 15y agoWe must do different kinds of sites, because I found that the defaults were too low - I had constant trouble with them till I increased them by like 1000 over what they were before.
- ck2 15y agoYou are passing more than 1000 variables per request? Maybe some crazy, poorly written ajax, I dunno. The default is 100 or 200, which might be low in some edge cases. suhosin.cookie.max_vars (default 100) suhosin.get.max_vars (default 100) suhosin.post.max_vars (default 200) suhosin.request.max_vars (default 200) To avoid the apache bug, set them no higher than 999. Oh do you mean my comment on GET length? Apache will happily pass PHP up to 8192 characters on a GET request which is insane and should not be allowed. Pass that much via post and restrict URLS to 1024 or less. Old IE won't go over 2k anyway.
- ars 15y agoNope, not ajax, not crazy, and not poorly written. Simply a large page where a client can easily and quickly updates prices on a large number of products. Each product has a number of fields, and there can be lots of products on the page (depending on the search parameters they chose).
- sjs 15y agoSix of one, half a dozen of the other. http://news.php.net/php.internals/57655 http://news.php.net/php.internals/57655
- rmccue 15y agoThere's a giant disagreement on php-internals at the moment as to the nature of Suhosin. The core developers argue that time would be better spent working on the core itself instead, and Stefan does not agree with that. The aforementioned post is Stefan's attempt to show why suhosin is needed. (I disagree personally, and I think Stefan's attitude is less than productive to the entire discussion.)
- X-Istence 15y agoSeeing as how SuHoSin's patch/extension together stop this flaw from even being exploitable I would say SuHoSin is perfect. Even on PHP 5.3.9 my servers were never exploitable because I utilised the SuHoSin patch/extension with sane defaults. I think any project that doesn't take "security" fixes into consideration, doesn't use code-review and lets developers that clearly have no business changing security sensitive code commit bad code could use a good safe-gaurd that fixes those issues. Yes, the time could be spent working on the core itself, but clearly that won't stop people from committing stuff they shouldn't be committing without having a qualified security guy checking off on it, so that won't help me have a secure running PHP installation...
- teoruiz 15y agoAnybody knows if it affects PHP 5.2.x?
- nikic 15y agoOnly if you backported the max_input_vars fix. (Or if your distro did it for you in case you don't do your own compiles.)
- maratd 15y agoIs it me or is PHP more lively these days? Critical updates are pushed immediately, they're fixing the broken tests, the community is more aggressive and there are interesting projects popping up. Feels like a spring cleaning.
- tszming 15y agoDebian unstable packages has recently disabled suhosin patch by default http://lists.debian.org/debian-devel/2012/02/msg00079.html http://lists.debian.org/debian-devel/2012/02/msg00079.html