| Summary: | dev-php/php: Vulnerable XML-RPC and PCRE libs | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Sune Kloppenborg Jeppesen (RETIRED) <jaervosz> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | php-bugs |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | B1 [glsa] jaervosz | ||
| Package list: | Runtime testing required: | --- | |
|
Description
Sune Kloppenborg Jeppesen (RETIRED)
2005-08-13 07:28:06 UTC
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 |