Bugzilla Bug 111032

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