Bugzilla Bug 102373

see bug #102324

Now instead see bug #102576 

If the PEAR XML-RPC module is still shipped in PHP proper ebuild, then it needs
to be fixed too (PEAR module is already fixed by sebastian, see bug 102576).

Stuart will bump it tonight.

PHP is probably also affected by the libpcre thing (see bug 103337). Would be a
good thing to fix both in one move.

Mandriva released an advisory about this :

=========================================================
 Package name:           php
 Advisory ID:            MDKSA-2005:152
 Date:                   August 25th, 2005

 Integer overflow in pcre_compile.c in Perl Compatible Regular
 Expressions (PCRE) before 6.2, as used in multiple products, allows
 attackers to execute arbitrary code via quantifier values in regular
 expressions, which leads to a heap-based buffer overflow.
 
 The php packages, as shipped, were built using a private copy of pcre.
 
 The updated packages have been rebuilt against the system pcre libs
 to correct this problem.

 a0a2f9a9e8241a515cf2b548beae4cb7  10.0/SRPMS/php-4.3.4-4.6.100mdk.src.rpm
==================================================

Still nothing upstream... how difficult is it to patch on our side ?

UPSTREAM has released PHP 5.0.5 that has the appropriate patch. The PHP_4_4
(next release: PHP 4.4.1) and HEAD (next release: PHP 6) branches have the patch
as well.

The release cycle for PHP 4.4.1 is supposed to start this week.

Sebastian: any news of the 4.4.1 ? We really are late in fixing this...

No, PHP 4.4.1 is delayed and not even in RC phase as of now.

Hm.

Sebastian: Could we patch our 4.4.0 using the things in CVS ?

We could do that (although I do not have the time at the moment to look into
this, I could only review a patch) but I do not think it is necessary since
updating dev-php/PEAR-XML_RPC to the current version solves the issue.

I'm a little more concerned by the PCRE lib. All untrusted regexps used in PHP
currently may turn themselves into arbitrary code zombies and bite us.

OK, I'm making a patch for 4.4.0, and I'll also take a look at 4.3.11 and
5.0.4,
since we need both in the tree to maintain backwards compatibility to older PHP
scripts (4.4.0 and 5.0.5 changed some things). I'll first do the patches for
dev-lang/php and upload them for a little testing to the PHP Overlay, if all
works  I'll also add them to the old PHP ebuilds and test, after that I'll see
to have someone update the tree (since I don't yet have CVS access), especially
dev-lang/php needs some more updates.
I'll keep you posted on this, best regards, CHTEKK.

Thank you, Luca, for taking care of this. I will glady review your patches and
help testing them.

Please make sure the version name of the patched version is "4.4.0-gentoo-r1"
(configure, configure.in, and main/php_version.h need to be edited for this),
for instance. This has been requested by UPSTREAM for these kinds of patches.

Sebastian, ok thanks, I modified configure.in so that it appens -gentoo-r1 to
the version of PHP (EXTRA_VERSION), and the configure and main/php_version.h are
regenerated afterwards, so they're also all up-to-date.
dev-lang/php is all patched, you can find 4.3.11-r1, 4.4.0-r1 and 5.0.4-r1 in
the latest PHP Overlay [1]. 5.0.5 and 5.1.0_rc1 aren't affected by the PCRE
vulnerability. The patches are quite straightforward, just a change to
ext/pcre/config.m4 and configure.in, and then the replacement for the
ext/pcre/pcrelib directory, wich is the latest CVS from PHP (PCRE 6.2 version).
The tarball containing the updated lib is currently being pulled from
dl.longitekk.com, my main download server. Please test the dev-lang/php fixes,
I'll start applying the patches to the old dev-php/php, dev-php/php-cgi and
dev-php/mod_php 4.3.11 and 4.4.0 versions and upload them also to the overlay in
a new directory just for this purpose, since we'll provide security fixes for
those till 8th January and they're needed. :)
Please do not commit dev-lang/php to the tree yet, the actual one in the overlay
needs more updates et all than just the ebuild to work (new eclasses, new
patches, etc.) and I need to write down a safe procedure to upgrade them in a
sane manner.
Best regards, CHTEKK.

[1] http://svn.gnqs.org/projects/gentoo-php-overlay/wiki

Ok I just finished also updated patches and ebuilds for dev-php/php,
dev-php/php-cgi and dev-php/mod_php.
Those are available at [1] for testing, it's only ebuilds + patches for this
particular problem, please test them and report back if they work correctly!
dev-php/mod_php-4.4.0-r2 is the one that will go stable, for old-style Apache
installations, dev-php/mod_php-4.4.0-r3 instead will remain keyworded unstable
and will be the one working with new-style Apache installations.
If no one has something to object, me and Hollow will get dev-lang/php and
related up to date tomorrow morning/noon, and then update also the old-style PHP
ebuilds around noon/afternoon. Once the patched ebuilds are in Portage I'll drop
a note here, so we can release a GLSA for this.
Best regards, CHTEKK.

[1]
http://svn.gnqs.org/projects/gentoo-php-overlay/browser/old-style-php-ebuild-for-security-fix/

The patch looks okay (I have no time to test it, sorry). Go ahead and commit
it,
thanks.

OK people, finally all committed to the tree, big thanks to Hollow for that. :)
dev-lang/php has seen the addition of -r1 releases wich fix this vulernability,
among other issues, and the old ebuilds were deleted. The KEYWORDS here are all
~ARCH for the arches that already did test dev-lang/php, this one will need no
intervention of the arch-teams since dev-lang/php will remain in ~ARCH until 8th
October 2005.
dev-php/php, dev-php/php-cgi and dev-php/mod_php also have seen new revisions
wich fix this vulnerability, the new revisions are already marked stable on x86
(because security bump) and ~ARCH on all other arches, arch-teams, please test
and mark stabl only the following ebuilds:

dev-php/php-4.3.11-r1
dev-php/php-4.4.0-r1
dev-php/php-cgi-4.3.11-r2
dev-php/php-cgi-4.4.0-r2
dev-php/mod_php-4.3.11-r1
dev-php/mod_php-4.4.0-r2

Since we need both 4.3.11 and 4.4.0 to be fixed and marked as stable in the tree
to maintain backwards compatibility (4.4.0 breaks compatibility to 4.3.11, and
therefore many PHP apps die).
dev-php/mod_php-4.4.0-r3 is the ebuild for the new-style Apache configuration
and remains marked as ~ARCH, so no need for arch-teams to stabilize that yet.
Best regards, CHTEKK.

Archs, please test and mark stable following instructions in previous comment.

@ arch-teams: little update, since the new Apache config layout was stabilized,
we also need to mark dev-php/mod_php-4.4.0-r3 as stable in addition to all the
other ebuilds listed above. For x86 this is already being done, thanks a lot! :)
Best regards, CHTEKK.

All stable on amd64. 

php and mod_php stable on ppc64. php-cgi was never marked ppc64 in any way. 

Stable on ppc and hppa.

All of these have been marked stable on alpha:

dev-php/php-4.3.11-r1
dev-php/php-4.4.0-r1
dev-php/php-cgi-4.3.11-r2
dev-php/php-cgi-4.4.0-r2
dev-php/mod_php-4.3.11-r1

The following package HAS NOT been marked stable and will probably take some time:

dev-php/mod_php-4.4.0-r2

It is against common sense do a big move like this in a security bump. The only
thing you do is waste our time and drive us crazy. PLEASE do things *with*
common sense; and if you have to backport patches, I don't care, it is part of
your job.

Cheers,
Ferdy

Gah... my bad, misread -r2 (as -r3). Sorry for the useless and pointless rant.
Marked alpha.

/me apologizes while stabbing himself

Cheers,
Ferdy

Still waiting on sparc to release GLSA.

Stable on SPARC (using mod_php-4.4.0-r2 because we are still on the old
layout).
 Sorry for the delay.

GLSA 200509-19
arm ia64 mips s390 should mark stable to benefit from GLSA