PHP 5.3.10 release delivers a critical security fix | Hacker News Reader

PHP 5.3.10 release delivers a critical security fix

php.net

50 pointsbrainless16 comments

Found this related article: http://thexploit.com/sec/critical-php-remote-vulnerability-i...

Six of one, half a dozen of the other.

http://news.php.net/php.internals/57655

There'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.)

Seeing 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...

Is 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.

Work 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.

We 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.

You 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.

Nope, 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).

Debian unstable packages has recently disabled suhosin patch by default

http://lists.debian.org/debian-devel/2012/02/msg00079.html

It'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.

Link to a PoC in JavaScript - anybody tested this? https://gist.github.com/1725489

Tested on one of my dedicated servers - definitely slows it down.

PoC for the wrong bug.

Anybody knows if it affects PHP 5.2.x?

Only 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.)

Reply on news.ycombinator.com