http://www.php.net/release_4_4_1.php PHP 4.4.1. Release Announcement The PHP Development Team would like to announce the immediate release of PHP 4.4.1. This is a bug fix release, which addresses some security problems too. The security issues that this release fixes are: Fixed a Cross Site Scripting (XSS) vulnerability in phpinfo() that could lead f.e. to cookie exposure, when a phpinfo() script is accidently left on a production server. Fixed multiple safe_mode/open_basedir bypass vulnerabilities in ext/curl and ext/gd that could lead to exposure of files normally not accessible due to safe_mode or open_basedir restrictions. Fixed a possible $GLOBALS overwrite problem in file upload handling, extract() and import_request_variables() that could lead to unexpected security holes in scripts assumed secure. (For more information, see here). Fixed a problem when a request was terminated due to memory_limit constraints during certain parse_str() calls. In some cases this can result in register_globals being turned on. Fixed an issue with trailing slashes in allowed basedirs. They were ignored by open_basedir checks, so that specified basedirs were handled as prefixes and not as full directory names. Fixed an issue with calling virtual() on Apache 2. This allowed bypassing of certain configuration directives like safe_mode or open_basedir. Updated to the latest pcrelib to fix a possible integer overflow vulnerability announced in CAN-2005-2491. This release also fixes 35 other defects, where the most important is the the fix that removes a notice when passing a by-reference result of a function as a by-reference value to another function. For a full list of changes in PHP 4.4.1, see the ChangeLog. http://www.php.net/ChangeLog-4.php
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
