This is not an ordinary security bug... See $URL for a full explanation. Basically, suhosin-0.9.27 improves PHP's random number generation and prevents webapps from doing stupid things like using (mt_)srand($predictable_seed). This is mostly a problem in webapps and should be fixed there, but in the meantime this new suhosin version provides a good workaround. It also mitigates the problem of shared PHP installations in case of random numbers, where an evil user could initialize the random number generator (which is shared) with 0 or something. All in all, these issues might lead to guessable tokens (such as those which are used for password reset services, confirmation emails, ...). As this greatly improves security in certain webapps (don't have a list of those though), I'm requesting early stabilization.
Arches, please test and mark stable: =dev-php5/suhosin-0.9.27 Target keywords: alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86 ~x86-fbsd Already stable: amd64 (by me) Testing can be done similar to dev-lang/php by trying certain webapps (phpMyAdmin, blog software, whatever) and making sure they still work as expected (i.e. with vanilla PHP).
x86 stable
Stable for HPPA.
ppc stable
alpha/ia64/sparc stable
ppc64 stable
I guess this one could be closed since all supported arches are stable?
Is the suhosin RNS installed/used by default for our PHP now?
CVE-2008-4107 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-4107): The (1) rand and (2) mt_rand functions in PHP 5.2.6 do not produce cryptographically strong random numbers, which allows attackers to leverage exposures in products that rely on these functions for security-relevant functionality, as demonstrated by the password-reset functionality in Joomla! 1.5.x and WordPress before 2.6.2, a different vulnerability than CVE-2008-2107, CVE-2008-2108, and CVE-2008-4102.
No, we are not enabling by default at the moment. Do you think we should? Upstream tries to convince distributions to drop using suhosin it all as they dislike any 3rd-party patches and claim that PHP already supports most of it (in 5.3+ though, and not everything either). I'd prefer to keep it as-is at the moment, simply enabling suhosin now might cause breakage (as certain settings can be too restrictive for some setups). We could enable it in 5.3+, but I don't know whether the benefit there is still that hight that it makes sense at all. Opinions?
Well, we need to do something about the issues that suhosn addresses and upstream does not really care. It is my understanding, suhosin is now enabled by default on Debian and Ubuntu systems, so web applications breakage should be resolved soon.
Well, what to do now? I'd rather not want to be the one who is responsible for the change of enabling it by default in php-5.2.. this is very likely to cause unwanted side effects. Whether or not to enable in 5.3 is something which has to be reevaluated, because certain things have improved in vanilla php (no, i don't have any details). So.. I'd really mark this as WONTFIX for 5.2. What'd work for me would be an ewarn regarding that (i.e. explicitly suggest to enable the USE flag, but noting the possible consequences).
Do we want it as default for 5.3? The decision should be made in the next one or two weeks.
Although suhosin is actively maintained and being applied to the 5.3 branch of PHP, it is likely to cause more problems than it solves. I suggest this only be enabled by default in hardened profiles.
Rating this B4. GLSA Vote: no.
GLSA Vote: no.
(In reply to comment #16) > GLSA Vote: no. > Thanks! Closing noglsa.
