Summary: | PHP 4.4.1 fixes several security issues | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Rajiv Aaron Manglani (RETIRED) <rajiv> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | brad, farcepest, php-bugs, shellsage |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://news.php.net/php.announce/57 | ||
Whiteboard: | A2? [glsa] | ||
Package list: | Runtime testing required: | --- |
Description
Rajiv Aaron Manglani (RETIRED)
2005-10-31 08:26:59 UTC
Some these are already fixed in dev-lang/php-4.4.0-r2. Nevertheless, the PHP Herd is working on getting PHP 4.4.1 into portage ASAP. *** Bug 111011 has been marked as a duplicate of this bug. *** *** Bug 111014 has been marked as a duplicate of this bug. *** *** Bug 111015 has been marked as a duplicate of this bug. *** There are also two other issues in PHP that we should try to fix at the same time if possible : bug 107602 and bug 108169... Note that the first is probably fixed in 4.4.1 (was fixed in CVS iirc), while the latter probably isn't. Hello I wish to report a issue with 4.4.1 I ran into while Upgrading from 4.4.0, because the Bugzilla DB on php.net does not permit to file a bug - the newest version which could be chosen from the drop down is 4.4.1RC1 - and my testing plattform is gentoo, I report here: On my testing plattform I have serveral CMS installed, the vhost containing papaya cms which heavily uses rewrite engine had segfaults in error log. I tracked it down that every request URL for a nonexistant file (favicon) triggers the segfault. Papaya rewrites the 404 for a custom error document, this is the trigger to reproduce this. A debug build of plain apache 2.0.55 and php 4.4.1 with no other modules involved shows this behavior, core dump and backtrace gives me no more information, much more digging seems to be nescessary. Downgrade to 4.4.0 solves this, its definetly introduced via 4.4.1. If anyone wants more info, having trouble to recreate a testcase, just ask... The reported vulnerabilities were fixed in CVS with the latest revisions of all PHP packages. For new-style PHP: dev-lang/php-4.3.11-r3 dev-lang/php-4.4.0-r3 dev-lang/php-4.4.1 dev-lang/php-5.0.4-r3 dev-lang/php-5.0.5-r3 For old-style PHP: dev-php/php-4.3.11-r3 dev-php/php-4.4.0-r3 dev-php/php-cgi-4.3.11-r4 dev-php/php-cgi-4.4.0-r4 dev-php/mod_php-4.3.11-r3 (old-style Apache config layout) dev-php/mod_php-4.4.0-r6 (old-style Apache config layout) dev-php/mod_php-4.4.0-r7 (new-style Apache config layout) Only old-style PHP needs to be stabled by the arch-teams, dev-lang/php does not need any particular keywording (though testing and adding to ~ARCH by the arch-teams who didn't already do it or anyway test the new revisions and dev-lang/php-4.4.1 is appreciated!). Bug 107602 also is fixed, bug 108169 instead will need to be fixed upstream, I'll try to reproduce and open a bug on php.net if it's possible to reproduce it . @ Alexander: please test with the latest dev-lang/php packages again, PHP 4.4.1 should have a fix _against_ segfaulting with mod_rewrite. If the problem still persists, either take it upstream to bugs.php.net or open a separate bug here on the Gentoo bugzilla, thanks. Best regards, CHTEKK. Ah, btw maybe you also want to include in the GLSA that bug 102943 and bug 109669 were also fixed, they are only problems with safe_mode/open_basedir, but were part of what PHP 4.4.1 fixes. Best regards, CHTEKK. Arches, please test and mark stable according to comment #7 Stable on ppc and hppa. Little update: I've just deleted dev-lang/php-4.4.1 and added dev-lang/php-4.4.1-r1, -r1 fixes a rather nasty crash with mod_rewrite and Apache2 (this is the problem Alexander was experiencing) and adds again support for Hardened-PHP (latest version 0.4.5). No intervention from any arch-team requested for this, it's purely fyi. Best regards, CHTEKK. FYI, seems there's a couple of annoying bugs and 4.4.2 will "likely" be out within the next "couple" of weeks. http://bugs.php.net/bug.php?id=35067 http://bugs.php.net/bug.php?id=35070 And the relevant discussion from internals@lists.php: http://thread.gmane.org/gmane.comp.php.devel/32987 x86 happy (In reply to comment #12) > FYI, seems there's a couple of annoying bugs and 4.4.2 will "likely" be out > within the next "couple" of weeks. > > http://bugs.php.net/bug.php?id=35067 CHTEKK, is our dev-php/php 4.4.0 backport vulnerable to this ? (In reply to comment #14) > (In reply to comment #12) > > FYI, seems there's a couple of annoying bugs and 4.4.2 will "likely" be out > > within the next "couple" of weeks. > > > > http://bugs.php.net/bug.php?id=35067 > > CHTEKK, is our dev-php/php 4.4.0 backport vulnerable to this ? Sadly yes. :( As I was patching the files for the vulnerabilities, I also checked what other patches and fixes were applied to the files in question, and if they weren't destructive and worked, I also applied them, and this was one of the fixes for basic_functions.c, and now they reverted it since it's a bug... Shall I change the patches for this? It's like deleting a couple of lines from the patch file to fix this. Best regards, CHTEKK. Well, I don't like the idea of pushing all users to upgrade to a version that *will* break existing functionality for common webapps like squirrelmail. So yes, I'd say we should fix it. Removing arches until this is done. Ccing x86 and hppa/ppc as they might want to act to protect their users from this. (In reply to comment #16) > Well, I don't like the idea of pushing all users to upgrade to a version that > *will* break existing functionality for common webapps like squirrelmail. > > So yes, I'd say we should fix it. Removing arches until this is done. Ccing x86 > and hppa/ppc as they might want to act to protect their users from this. Ok I fixed this problem and another one with the Apache2 SAPI, and revbumped all involved ebuilds to be sure users get the updates. For the revbumped ebuilds, I've dropped the keywords back to ~ARCH, so the arches that already marked stable (ppc, hppa, alpha and x86) should please retest the latest revisions and remark stable, thanks. :) So, in the end, the ebuilds that need to be checked and stabled by the arch-teams now are: dev-php/php-4.3.11-r4 dev-php/php-4.4.0-r4 dev-php/php-cgi-4.3.11-r5 dev-php/php-cgi-4.4.0-r5 dev-php/mod_php-4.3.11-r4 (old-style Apache config layout) dev-php/mod_php-4.4.0-r8 (old-style Apache config layout) dev-php/mod_php-4.4.0-r9 (new-style Apache config layout) Thanks and best regards, CHTEKK. Hope this is the right one... Calling back arches to play the game. See post above for the correct -rN to test and mark stable. can we just deKEYWORD dev-php/{php,php-cgi,mod_php} and just go with dev-lang/php or would you guys prefer to wait ? i got tired real fast with trying to KEYWORD those three packages for my arches and the new dev-lang/php works nicely in all my envs (arch/libc combos) I'd rather not correlate security fix and difficult upgrade. We did that with apache lately, did not work well. Hopefully this is the last security fixor before dev-lang/php gets stable. (In reply to comment #19) > can we just deKEYWORD dev-php/{php,php-cgi,mod_php} and just go with > dev-lang/php or would you guys prefer to wait ? i got tired real fast > with trying to KEYWORD those three packages for my arches and the new > dev-lang/php works nicely in all my envs (arch/libc combos) Not really, I'm with Thierry here, and dev-lang/php isn't finished yet, we still lack the php-toolkit that I should hopefully be able to do in the next weeks, so for now old-style remains stable, dev-lang/php unstable, there's still some stuff to do for it and documentation to publish etc., we want this to go as smoothly as possible once it's time for it. :) Best regards, CHTEKK. sparc stable. Stable on ppc and hppa x86 stable All should be done on alpha now. Cheers, Ferdy all stable on amd64 GLSA is waiting on ppc64 to mark stable. If someone would help me through this, I'd be happy to keyword. I'm familiar with php and apache but not to the detail I think will be required. I usually hang out on #gentoo-ppc64 and have a fast enough machine for compilations to go quickly. Fair enough? marked ppc64 stable now. thanks for the help. GLSA 200511-08 arm, ia64, mips and s390 should mark stable to benefit from GLSA |