2 vulnerabilities have been found in php... the second one only seem to affect PHP5 which is ~arch masked atm
PHP Array Processing Error in Handling RFC1867 MIME Formatting May Let Remote Users Overwrite Memory
CVE Reference: GENERIC-MAP-NOMATCH
Impact: Modification of system information, Modification of user information
Fix Available: Yes Vendor Confirmed: Yes
Version(s): 5.0.1 and prior versions
A vulnerability was reported in PHP in the processing of MIME data. A remote user may be able to cause memory to be overwritten.
Stefano Di Paola reported that there is an array processing error in the SAPI_POST_HANDLER_FUNC() function 'rfc1867.c'. A remote user may be able to cause the $_FILES array elements to be overwritten.
A remote user may be able to overwrite memory on the target system.
A fix is available via CVS at: http://cvs.php.net/php-src/main/rfc1867.c
PHP Array Parsing Error in php_variables May Disclose Memory Contents via phpinfo()
SecurityTracker Alert ID: 1011279
CVE Reference: GENERIC-MAP-NOMATCH
Disclosure of system information, Disclosure of user information
Fix Available: Yes Exploit Included: Yes Vendor Confirmed: Yes
Version(s): 5.0 - 5.0.1
A vulnerability was reported in PHP in the phpinfo() function. A remote user may be able to obtain memory contents.
Stefano Di Paola reported that an array parsing error in 'php_variables.c' may cause the system to display arbitrary memory contents. A remote user can append a GET, POST, or COOKIE variable array to a request to trigger the flaw.
A demonstration exploit is shown [where 'phpinfo.php' contains the phpinfo() function]:
$ curl "http://www.example.com/phpinfo.php" -d `perl -e 'print "f"x100;print "[g][=1"'`
Alternately, the file may contain a print_r($_REQUEST) function call.
A remote user may be able to obtain random memory contents.
A fix is available via CVS:
Not sure the provided patch applies to PHP4...
PHP team, please comment.
It doesn't look to me like this affects PHP4...
Theorically, the RFC1867 thing affects all versions (but I didn't check the code, you tell me). The other (phpinfo leak) specifically affects version 5.x.
KrispyKringle, you will coordinate this one.
Seems to me that http://cvs.php.net/php-src/main/rfc1867.c contains a fix for both the 5.0 and the 4.3 branches.
PHP team, we're waiting on you.
PHP team, this is a fairly minor patch. Would someone give me some indication that something is being done? :) Thanks.
work in progress now.
php-5.0.1-securityfix.tgz on the mirrors with two patches for PHP5.0.1
For the PHP4 series I'm just going to roll out 4.3.9rc3 which contains the fixes already.
upstream has released 4.3.9 and 5.0.2, which roll these fixes and more in.
Should have them in the tree and tested on my side by the end of the day.
in cvs now.
still testing them.
Target keywords for PHP 4.3.9 : "x86 ppc sparc alpha hppa amd64 ia64 ~s390 ppc64"
No stable keywords needed for PHP 5.0.2.
Arches, please mark dev-php/php-4.3.9 stable.
stable on ppc
mod_php-4.3.9, php-4.3.9 & php-cgi-4.3.9 sparc stable.
AFAIK the three packages should be stable and not just php-4.3.9, please tell ppc because they just missed the others :)
Thx Gustavo for pointing that out.
Target keywords are :
dev-php/php-4.3.9 : "x86 ppc sparc alpha hppa amd64 ia64 ~s390 ppc64"
dev-php/mod_php-4.3.9 : "x86 ppc sparc alpha hppa amd64 ia64 ~s390"
dev-php/php-cgi-4.3.9 : "x86 sparc alpha hppa ppc ia64"
Recalling ppc who needs two more stable keywords.
Stable on alpha.
4.3.9 stable on x86 - now that i've tested the crap out of it.
php-5.0.2 doesn't seem stable at all :-(.
ia64 has those three packages (4.3.9) stable now
Why are we closing this bug? Still waiting on amd64 to mark stable, and we still need a GLSA.
amd64, we need some loving.
closing of bug was accident
building on hppa now
had a problem with sablotron but resolved that myself
hppa stable now
amd64 stable now, enjoy
stable on ppc64, thanks!