From $url: Description: ------------ Using the attached test-script with just a large amount of data (e.g. 8kb of just "x") segfaults php. Tried with 5.3.3 (Fedora) and also some 5.3.4-snapshot that I could get hold of. Crashed for me with around 8kb of data. If it works fine for you, maybe increase that limit to 16kb or so. Test script: --------------- <?php $email = file_get_contents('x.data'); $r = filter_var($email, FILTER_VALIDATE_EMAIL); var_dump($r); // and just dump a large number of characters like "x" in x.data // for a in `seq 1 8000`; do echo -n x>>x.data; done
*** Bug 344061 has been marked as a duplicate of this bug. ***
PHP 5.3.4 and 5.2.15 have just been released, which remedy this and other vulnerabilities. http://www.php.net/archive/2010.php#id2010-12-10-1 Security fixes in 5.3.4 are listed as: * Fixed crash in zip extract method (possible CWE-170). * Paths with NULL in them (foo\0bar.txt) are now considered as invalid (CVE-2006-7243). * Fixed a possible double free in imap extension (Identified by Mateusz Kocielski). (CVE-2010-4150). * Fixed NULL pointer dereference in ZipArchive::getArchiveComment. (CVE-2010-3709). * Fixed possible flaw in open_basedir (CVE-2010-3436). * Fixed MOPS-2010-24, fix string validation. (CVE-2010-2950). * Fixed symbolic resolution support when the target is a DFS share. * Fixed bug #52929 (Segfault in filter_var with FILTER_VALIDATE_EMAIL with large amount of data) (CVE-2010-3710). And the security fixes in 5.2.15 are listed as: * Fixed extract() to do not overwrite $GLOBALS and $this when using EXTR_OVERWRITE. * Fixed crash in zip extract method (possible CWE-170). * Fixed a possible double free in imap extension. * Fixed possible flaw in open_basedir (CVE-2010-3436). * Fixed NULL pointer dereference in ZipArchive::getArchiveComment. (CVE-2010-3709). * Fixed bug #52929 (Segfault in filter_var with FILTER_VALIDATE_EMAIL with large amount of data).
We are now at 5.2.16 and 5.3.4 Ebuilds have been committed to CVS. This is somewhat peculiar as the committed ebuilds use the minor version slotted architecture, that is not even keyworded on some arches. Security okay with moving to stable under this circumstances?
(In reply to comment #3) > Security okay with moving to stable under this circumstances? Sure.
Arches, please test and mark stable: =dev-lang/php-5.2.16 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86" =dev-lang/php-5.3.4 Target keywords : "amd64 hppa x86"
x86 stable
Actually, we also need to stabilize dev-php/PEAR-PEAR-1.9.1-r3, otherwise packages depending on PEAR are broken. x86 stable.
amd64 ok
amd64 done. Thanks Agostino
Folks, this wasn't done very smoothly: 01:54 < kev009> php bump broke my server 01:54 < kev009> apache 70_mod_php.conf is looking for /usr/lib/apache2/modules/libphp5.so 01:55 < kev009> but php is now /usr/lib/php5.3/apache2/libphp5.so 01:55 < kev009> x86 php and apache2 01:57 < kev009> also, would be cool if pecl-apc invalidated on upgrads (might need a php-cleaner?) 01:59 < kev009> looks like stable pecl-apc is broken wrt stable php too
(In reply to comment #10) > Folks, this wasn't done very smoothly: Sorry about that. > 01:54 < kev009> php bump broke my server > 01:54 < kev009> apache 70_mod_php.conf is looking for > /usr/lib/apache2/modules/libphp5.so Have you run "eselect php set apache2 php5.3"? > 01:57 < kev009> also, would be cool if pecl-apc invalidated on upgrads (might > need a php-cleaner?) Why? After upgrading php, you'd need to restart apache anyway. > 01:59 < kev009> looks like stable pecl-apc is broken wrt stable php too Yeah, along with every other minor version slotting aware stable package. Here's a list of packages that need arch love: pecl-apc pecl-crack pecl-fileinfo pecl-htscanner pecl-http pecl-imagick pecl-mailparse pecl-mcve pecl-memcache pecl-ssh2 pecl-syck pecl-yaz We (the php team) provided new versions for everything in the tree, but some are either keywordless or keyworded ~arch. Didn't think about that when we decided to provide a minor version slotted PHP only. Two ways we can get out of this: I provide php-5.3.4-r1 as a bump of php-5.3.3-r1 (the slot0 variant), as well as php-5.2.16-r1 as a slot0 ebuild. Doesn't make me happy but will probably be the quickest thing. Or all subscribed arches check and stable the latest version of the aforementioned packages. I'm sorry the php team only provided minor version slotting aware ebuilds for the most current version (so in most cases ~arch ebuilds). If it helps you choose path 2, I can provide minor version slotted ebuilds of these packages equal to your current stable ebuild (so all that changes is that the package now builds against php5.2 *and* php5.3) Well, any way is fine with me. Thing is: we're still waiting for the suhosin patch to adapt to 5.3.4. So the current ebuild doesn't have that patch. QA has told me they dislike adding in Suhosin after the ebuild has gone stable. So PHP will probably see a revbump anyway. If arches are quick enough, we can have that twelve packages stable before that one is out. That'd be a nice christmas present for the php team :) Hunt me down on IRC if you want to talk about this mess.
> > > 01:54 < kev009> php bump broke my server > > 01:54 < kev009> apache 70_mod_php.conf is looking for > > /usr/lib/apache2/modules/libphp5.so > > Have you run "eselect php set apache2 php5.3"? This would be fine if 1) eselect-php were stable, 2) the php bump depended on eselect-php, 3) there was a package warning and news item about the need to run this command > > 01:57 < kev009> also, would be cool if pecl-apc invalidated on upgrads (might > > need a php-cleaner?) > > Why? After upgrading php, you'd need to restart apache anyway. It's my understanding that pecl modules need to be rebuilt on even minor updates. Please disregard if this is incorrect. > > We (the php team) provided new versions for everything in the tree, but some > are either keywordless or keyworded ~arch. Didn't think about that when we > decided to provide a minor version slotted PHP only. I hate to be a whiner, but this really seems like no stable arch testing was done before hand. At this point, lets just push to get the state of the art stable. Re-add the archs that have stabilized and add the pecl- packages as dependencies of this bug.
(In reply to comment #12) > > > > > 01:54 < kev009> php bump broke my server > > > 01:54 < kev009> apache 70_mod_php.conf is looking for > > > /usr/lib/apache2/modules/libphp5.so > > > > Have you run "eselect php set apache2 php5.3"? > > This would be fine if 1) eselect-php were stable, 2) the php bump depended on > eselect-php, 3) there was a package warning and news item about the need to run > this command Please disregard 1, it seems this is the case.
Poor arch team testing. So much stuff is broken now. Hate to complain, but..man...I would revert.
Maybe it is also nice to see that since the slotting has changed, there was also a need to create a new config location, from /etc/php/apache2-php5 to /etc/php/apache2-php5.3 (same for cli and presumable cgi/fpm). This means that after restarting apache, you're running a stock config. Again, this would be no real issue when this is stated in a clear package message or news item. Security bumps should be based upon the previous stable ebuild, they certainly should not include packaging feature changes, such as your latest adventures in the world of slotting.
Dear PHP Team! I just updated the php on two server (One X86+php5.3.4 and one AMD64+php5.2.16). Everythings works as expected. The only annoying thing was that xcache and suhosin extensions still unstable, and the keywords requires some hacking because of this. Cheers, Gergely
The remaining arches need to look at bug 349659 while doing this one.
Stable for HPPA.
ppc64 done
Stable on alpha.
Tested on SPARC, via eselect-php, both working and found to work just fine with default configuration. Tested via Apache with a web browser and a simple index.php page. Please stabilise.
New versions of php have been released. I will call for stabilization of those versions in bug 350908. Thanks, folks. We can/will eventually GLSA these with other PHP issues. GLSA Vote: yes, once bug 350908 is done.
ping?
CVE-2010-4700 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-4700): The set_magic_quotes_runtime function in PHP 5.3.2 and 5.3.3, when the MySQLi extension is used, does not properly interact with use of the mysqli_fetch_assoc function, which might make it easier for context-dependent attackers to conduct SQL injection attacks via crafted input that had been properly handled in earlier PHP versions.
CVE-2010-4699 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-4699): The iconv_mime_decode_headers function in the Iconv extension in PHP before 5.3.4 does not properly handle encodings that are unrecognized by the iconv and mbstring (aka Multibyte String) implementations, which allows remote attackers to trigger an incomplete output array, and possibly bypass spam detection or have unspecified other impact, via a crafted Subject header in an e-mail message, as demonstrated by the ks_c_5601-1987 character set. CVE-2010-4698 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-4698): Stack-based buffer overflow in the GD extension in PHP before 5.2.15 and 5.3.x before 5.3.4 allows context-dependent attackers to cause a denial of service (application crash) via a large number of anti-aliasing steps in an argument to the imagepstext function. CVE-2010-4697 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-4697): Use-after-free vulnerability in the Zend engine in PHP before 5.2.15 and 5.3.x before 5.3.4 might allow context-dependent attackers to cause a denial of service (heap memory corruption) or have unspecified other impact via vectors related to use of __set, __get, __isset, and __unset methods on objects accessed by a reference. CVE-2010-4409 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-4409): Integer overflow in the NumberFormatter::getSymbol (aka numfmt_get_symbol) function in PHP 5.3.3 and earlier allows context-dependent attackers to cause a denial of service (application crash) via an invalid argument. CVE-2010-4150 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-4150): Double free vulnerability in the imap_do_open function in the IMAP extension (ext/imap/php_imap.c) in PHP 5.2 before 5.2.15 and 5.3 before 5.3.4 allows attackers to cause a denial of service (memory corruption) or possibly execute arbitrary code via unspecified vectors. CVE-2010-3710 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-3710): Stack consumption vulnerability in the filter_var function in PHP 5.2.x through 5.2.14 and 5.3.x through 5.3.3, when FILTER_VALIDATE_EMAIL mode is used, allows remote attackers to cause a denial of service (memory consumption and application crash) via a long e-mail address string. CVE-2010-3709 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-3709): The ZipArchive::getArchiveComment function in PHP 5.2.x through 5.2.14 and 5.3.x through 5.3.3 allows context-dependent attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted ZIP archive. CVE-2010-3436 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-3436): fopen_wrappers.c in PHP 5.3.x through 5.3.3 might allow remote attackers to bypass open_basedir restrictions via vectors related to the length of a filename. CVE-2010-2950 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-2950): Format string vulnerability in stream.c in the phar extension in PHP 5.3.x through 5.3.3 allows context-dependent attackers to obtain sensitive information (memory contents) and possibly execute arbitrary code via a crafted phar:// URI that is not properly handled by the phar_stream_flush function, leading to errors in the php_stream_wrapper_log_error function. NOTE: this vulnerability exists because of an incomplete fix for CVE-2010-2094.
CVE-2011-0753 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-0753): Race condition in the PCNTL extension in PHP before 5.3.4, when a user-defined signal handler exists, might allow context-dependent attackers to cause a denial of service (memory corruption) via a large number of concurrent signals.
CVE-2011-0752 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-0752): The extract function in PHP before 5.2.15 does not prevent use of the EXTR_OVERWRITE parameter to overwrite (1) the GLOBALS superglobal array and (2) the this variable, which allows context-dependent attackers to bypass intended access restrictions by modifying data structures that were not intended to depend on external input, a related issue to CVE-2005-2691 and CVE-2006-3758.
CVE-2011-0755 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-0755): Integer overflow in the mt_rand function in PHP before 5.3.4 might make it easier for context-dependent attackers to predict the return values by leveraging a script's use of a large max parameter, as demonstrated by a value that exceeds mt_getrandmax.
This issue was resolved and addressed in GLSA 201110-06 at http://security.gentoo.org/glsa/glsa-201110-06.xml by GLSA coordinator Tobias Heinlein (keytoaster).