Stefan Esser reported these issues to vendor-sec. [01] ext/shmop/shmop.c - shmop_write() out of bounds memory write access CAN-2004-1018 http://cvs.php.net/diff.php/php-src/ext/shmop/shmop.c?r1=1.23.8.2&r2=1.23.8.3&ty=h credits: Stefano Di Paola / WiSEC [02] ext/standard/pack.c - pack() integer overflows leading to heap bufferoverflow ext/standard/pack.c - unpack() integer underflow leading to heap info leak CAN-2004-1018 (Yes same as [01]) http://cvs.php.net/diff.php/php-src/ext/standard/pack.c?r1=1.53&r2=1.54&ty=h credits: Stefan Esser [03] etx/standard/var_unserializer.c etx/standard/var_unserializer.re - possible information leaks/overflows CAN-2004-1019 http://cvs.php.net/diff.php/php-src/ext/standard/var_unserializer.re?r1=1.11.4.3&r2=1.11.4.4&ty=h http://cvs.php.net/diff.php/php-src/ext/standard/var_unserializer.c?r1=1.18.4.8&r2=1.18.4.9&ty=h credits: Marcus Boerger (later also reported by Sec-Consult) [04] main/rfc1867.c - magic_quotes_gpc could lead to one level directory traversal (attention: the filename argument should be handled by any web application as potential malicious user input and therefore never used directly anyway. ) http://cvs.php.net/diff.php/php-src/main/rfc1867.c?r1=1.122.2.27&r2=1.122.2.28&ty=h credits: Daniel Fabian / Sec-Consult Only PHP 4.3.9 is affected (NOT PHP 5 or PHP < 4.3.9) ----------------------------------------------------- [05] ext/standard/string.c - addslashes (and therefore magic_quotes_gpc) does not properly escape \0 CAN-2004-1020 http://cvs.php.net/diff.php/php-src/ext/standard/string.c?r1=1.333.2.44&r2=1.333.2.45&ty=h credits: Daniel Fabian / Sec-Consult All issues but [05] should also affect FC2. I'm marking this issue as security sensitive since the upstream release announcing this fix. We'll make this public when the rest of the world knows about it.
Here are the additional issues. [06] etx/standard/var_unserializer.c etx/standard/var_unserializer.re - negative reference index array underflow A negative index in a reference could leak to exploitable memory corruption. (NOTE: phpBB2 which is very famous uses unserialize on value of COOKIE, so this is remote exploitable) http://cvs.php.net/diff.php/php-src/ext/standard/var_unserializer.c?r1=1.18.4.11&r2=1.18.4.12&ty=h Credits: Stefan Esser [07] etx/standard/var_unserializer.c etx/standard/var_unserializer.re - reference to already freed array element A reference to an already freed zvalue can lead to my special friend: controlling a ZendHashTable incl. its destructor pointer. Due to the Zend Memory Cache it is easy to create a string that when unserialize is performed on it will result in cross platform jumping to a specifix EIP. (NOTE: phpBB2 is more or less easily exploitable with this, PoC exists) http://cvs.php.net/diff.php/php-src/ext/standard/var_unserializer.re?f=&r1=0&tr1=1.11.4.6&ty=h&r2=0&tr2=1.11.4.8 Credits: Stefan Esser [08] TSRM/tsrm_virtual_cwd.c - virtual_popen() safe_mode_exec_dir bypass When PHP is running multithreaded (f.e. multithreaded apache2, roxen-zts, ...) popen() automaticly gets a "cd CURRENTDIR ; " prepended. This happens directly before execution and after all checks. This means a script could create a directory with shellcommands in its name and execute them. Even if safe_mode_exec_dir is set to something like "/wont/ever/execute/anything/because/this/dir/does/not/exist" http://cvs.php.net/diff.php/TSRM/tsrm_virtual_cwd.c?r1=1.41.2.7&r2=1.41.2.8&ty=h Credits: Stefan Esser [09] TSRM/tsrm_virtual_cwd.c - virtual_file_ex() does not protect itself against malfunctional realpah() In some realpath() implementations (f.e. FreeBSD and OpenBSD (until a few days ago)) truncate the input string at MAXPATHLEN-1 bytes. This means if someone tries to do (with %00 properly escaped) include "modules/$modulname/bla.inc.php"; it is possible on these platforms to make $modulname very long so that realpath() automaticly cuts away the unwanted stuff in the end. [10] main/safe_mode.c - Overlong filename fools security checks I already mailed vendor-sec in May about the mad differences in realpath() on all those systems. glibc allows f.e. "/etc/hosts/../passwd" and allows overlong input filenames. Combined with the fact that the safe_mode checks strlcpy()s the filename into a buffer of the length MAXPATHLEN it is possible to do something like include "$LONG_PATH_THAT_I_AM_ALLOWED_TO_INCLUDE/../../../../etc/passwd" safe_mode checks will say: okay you can include the file, because it's name is truncated before the /../ start and then later the complete path is taken for inclusion. http://cvs.php.net/diff.php/php-src/main/safe_mode.c?r1=1.51.2.4&r2=1.51.2.5&ty=h [11] ext/exif/exif.c - exif_read_data() overflow on long sectionname Imagefile containing malicious exif data can trigger stack overflow. http://cvs.php.net/diff.php/php-src/ext/exif/exif.c?r1=1.118.2.28&r2=1.118.2.29&ty=h Credits: Ilia Alshanetsky
I forgot the CVE id's in my previous post. = CAN-2004-1019 [06] etx/standard/var_unserializer.c etx/standard/var_unserializer.re - negative reference index array underflow = CAN-2004-1019 [07] etx/standard/var_unserializer.c etx/standard/var_unserializer.re - reference to already freed array element = CAN-2004-1063 (Arbitrary command execution) [08] TSRM/tsrm_virtual_cwd.c - virtual_popen() safe_mode_exec_dir bypass = CAN-2004-1064 (arbitrary file access through path truncation) [09] TSRM/tsrm_virtual_cwd.c - virtual_file_ex() does not protect itself against malfunctional realpah() = CAN-2004-1064 (arbitrary file access through path truncation) [10] main/safe_mode.c - Overlong filename fools security checks = CAN-2004-1065 (Stack overflow) [11] ext/exif/exif.c - exif_read_data() overflow on long sectionname
*** Bug 144259 has been marked as a duplicate of this bug. ***
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-032.html