The usual procedure... 1. Crash in SPL: RecursiveIteratorIterator (php bug #41828 [1]) Low/no impact, can only be caused by a programming error 2. Crash in exif_read_data() (php bug #44388 [2]) This function is often used with user-supplied data (images), so it might allow for remote DoS. 3. printf() integer overflow (CVE-2008-1384) Low/no impact, the user would need to able to influence the format string. 4. Incorrect handling of multibyte chars inside escapeshellcmd() Assuming that escaping does not take place properly, this might enable remote users to execute arbitrary shell code in certain web apps. I'm not completely sure whether this is really the case as I didn't find any way to easily reproduce it, but judging from the comments and the fix, I'd say this is the case. 5. imap_setacl() crash (php bug #44557 [3]) Low/no impact, programmer has do to something wrong to trigger it. Only #4 looks pretty severe to me. [1] http://bugs.php.net/bug.php?id=41828 [2] http://bugs.php.net/bug.php?id=44388 [3] http://bugs.php.net/bug.php?id=44557
_rc3 in the tree now.
Arches, please test and mark stable: =dev-lang/php-5.2.6_rc3 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 release s390 sh sparc x86"
(In reply to comment #2) > Arches, please test and mark stable: > =dev-lang/php-5.2.6_rc3 > Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 release s390 sh sparc > x86" > the manifest got b0rked during the distribution-process to the rsync mirrors, adding mirror-admins therefore.
ppc and ppc64 done
ppc and ppc64 aren't done.
Ah, now they are. And stable for HPPA.
Stable on amd64. dertobi123, do you know what exactly happened and who/what is at fault? "!!! A file is not listed in the Manifest: '/usr/portage/dev-lang/php/php-5.2.5-r1.ebuild'" -- this is what Kuja^ reported in #gentoo-php at 17:05:35 (CET). Might be something different though.
(In reply to comment #7) > dertobi123, do you know what exactly happened and who/what is at fault? > "!!! A file is not listed in the Manifest: > '/usr/portage/dev-lang/php/php-5.2.5-r1.ebuild'" -- this is what Kuja^ reported > in #gentoo-php at 17:05:35 (CET). Might be something different though. Not exactly, the manifest contained the maven changelog, the manifest in cvs was ok though.I checked again a few minutes ago and it looks like the correct manifest is distributed again. *shrugs*
x86 stable
alpha/ia64/sparc stable
Fixed in release snapshot.
*sigh* I committed yet another revision (-r1) with a fix for phpbug 44564 [1]. Not sure if it is severe enough to ask for stabilization again. It's a regression introduced in php-5.2.6_rc3, and it basically makes escapeshellarg() and escapeshellcmd() functions discard any multibyte data, e.g. umlauts, which is of course not desired. The patch hopefully fixes it, but I won't ensure anyone that this is the last attempt at fixing this. I've committed it right now as a Gentoo user initially reported the problem and as I'll be away for a week... [1] http://bugs.php.net/bug.php?id=44564
Bleh... the patch might be wrong indeed, as this mailing list message suggests [1]. If anyone finds a working patch, feel free to bump while I'm away. [1] http://thread.gmane.org/gmane.comp.php.cvs.general/38497/focus=38505
request filed
I'll set this ebuild again for the bad patch
So.. upstream released rc4 and I just committed it to the tree. It has the same patch as rc3-r1, there is no new fix for the problem. Either this only happens on some systems (only one php dev reported that the bug fix did not work for him, it works fine for me) or it simply was some confusion. Not much we can do about and having the patch is still better than not having it, so... But... once again, we have some new issues which got fixed with rc4. (continuing the list from above) 6. Possible stack overflow in reading of FastCGI packets No real details available, I'm not able to rate the severity or impact of this problem. Last time there was a similar issue it was possible to read arbitrary files remotely (in combination with the lighttpd issue) 7. FastCGI packets contain a padding (which is supposed to be \0) which was apparently not initialized properly. This could lead to disclosure of small parts of the memory, if I got it right. As only the web server receives these packages, I don't really think it should be rated as a security issue? 8. imap_headerinfo() memory corruption / crash (php bug #44613 [4]) Probably only triggerable by the developer of the code as noone should pass user input to this function. I'm really unsure about #6. Anyway, what should we do? Stable now, mainly to get #6 fixed and the fix for the fix of the escapeshell*() problems? php-5.2.6 final is supposed to be released on April 11th or so, but well, it has already been delayed so that might happen again... [4] http://bugs.php.net/bug.php?id=44613
ping?
(4) is http://cvs.php.net/viewvc.cgi/php-src/ext/standard/exec.c?r1=1.113.2.3.2.4&r2=1.113.2.3.2.5&pathrev=PHP_5_2
Arches, please test and mark stable: =dev-lang/php-5.2.6_rc4 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 release s390 sh sparc x86"
ppc64 stable
amd64/x86 stable, please note: * QA Notice: 'aclocal' called by php5_2-sapi_src_unpack: dev-lang/php-5.2.6_rc4 * Use autotools.eclass instead of calling 'aclocal' directly. ... * Running libtoolize * QA Notice: 'libtoolize' called by php5_2-sapi_src_unpack: dev-lang/php-5.2.6_rc4 * Use autotools.eclass instead of calling 'libtoolize' directly.
alpha/ia64/sparc stable, see you at rc5 :P
Stable for HPPA.
ppc stable
Fixed in release snapshot. All security supported archs done; whiteboard -> glsa.
Ok, Stefan Esser replied to my mail (security@g.o was CC'ed). Summary: Issue #4 allows for shell command injection, but only in configurations which have set a default locale of SJIS, EUC-KR, GBK or similar multi-byte things. On a different note, he mentioned a random number seeding weakness, this will probably be worth including in our GLSA. Adivsories for both issues will be published by him in the very near future. ;)
issue (6) has gotten CVE-2008-2050: Stack-based buffer overflow in the FastCGI SAPI (fastcgi.c) in PHP before 5.2.6 has unknown impact and attack vectors
issue (4) has gotten CVE-2008-2051: The escapeshellcmd API function in PHP before 5.2.6 has unknown impact and context-dependent attack vectors related to "incomplete multibyte chars."
(In reply to comment #26) > Ok, Stefan Esser replied to my mail (security@g.o was CC'ed). Summary: Issue #4 > allows for shell command injection, but only in configurations which have set a > default locale of SJIS, EUC-KR, GBK or similar multi-byte things. http://www.sektioneins.de/advisories/SE-2008-03.txt > On a different note, he mentioned a random number seeding weakness, this will > probably be worth including in our GLSA. http://www.sektioneins.de/advisories/SE-2008-02.txt (CVE requested by rbu)
php-5.2.6RC5 and final solve a 64 bit issue regarding stream_select (and possibly other int/long 64-bit related issues). See http://bugs.php.net/bug.php?id=42682 We also had a strange segfault issue with pecl-memcache which is gone after upgrading to 5.2.6 final. I have 32bit and 64bit production boxes running 5.2.6 for over a day now without issues, so it seems pretty solid to me.
(In reply to comment #29) > http://www.sektioneins.de/advisories/SE-2008-02.txt (CVE requested by rbu) CVE-2008-2107
... and CVE-2008-2107
(In reply to comment #32) > ... and CVE-2008-2107 Did you mean CVE-2008-2108? It describes a problem at the very same place with the very same impact, but because of a different reason (precision) and on a different platform (64bit systems).
GLSA 200811-05, thanks everyone, especially hoffie.