

PHP 5.3.10 release delivers a critical security fix - brainless
http://www.php.net/archive/2012.php#id2012-02-02-1

======
wildmXranat
Found this related article: [http://thexploit.com/sec/critical-php-remote-
vulnerability-i...](http://thexploit.com/sec/critical-php-remote-
vulnerability-introduced-in-fix-for-php-hashtable-collision-dos/)

------
sjs
Six of one, half a dozen of the other.

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

~~~
rmccue
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.)

~~~
X-Istence
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...

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

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

~~~
ars
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.

~~~
ck2
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.

~~~
ars
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).

------
tszming
Debian unstable packages has recently disabled suhosin patch by default

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

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

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

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

------
teoruiz
Anybody knows if it affects PHP 5.2.x?

~~~
nikic
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.)

