| Summary: | dev-php/php: Multiple vulnerabilities (Vendor-Sec) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Sune Kloppenborg Jeppesen (RETIRED) <jaervosz> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | robbat2 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | A2? [] jaervosz / 20041215 CLASSIFIED | ||
| Package list: | Runtime testing required: | --- | |
|
Description
Sune Kloppenborg Jeppesen (RETIRED)
2004-11-28 08:14:30 UTC
PHP 4.3.10 and PHP 5.0.3 will be released within the next two weeks to fix these issues. Bug access is confidential for now. Do we try to build a patched version or do we just wait for upstream ? We wait for upstream, not all issues are patched. Stefan Esser just reported more problems: [06] etx/standard/var_unserializer.c We wait for upstream, not all issues are patched. Stefan Esser just reported more problems: [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) NO FIX IN CVS YET 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. http://cvs.php.net/diff.php/TSRM/tsrm_virtual_cwd.c?f=&r1=0&tr1=1.41.2.4&ty=h&r2=0&tr2=1.41.2.7 Credits: Stefan Esser [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 Credits: Stefan Esser More updates: [07] is now fixed in our CVS 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 and well I forgot to mention one possible overflow in the exif extension triggerable by a malicious image file. [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 CVE ids allocated: = CAN-2004-1018 CVE ids allocated: = CAN-2004-1018 (all bounds/over/under flaws) [01] ext/shmop/shmop.c - shmop_write() out of bounds memory write access = CAN-2004-1018 (all bounds/over/under flaws) [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-1019 [03] etx/standard/var_unserializer.c etx/standard/var_unserializer.re - possible information leaks/overflows = NO CVE ID [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. ) = CAN-2004-1020. [05] ext/standard/string.c - addslashes (and therefore magic_quotes_gpc) does not properly escape \0 = 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 Some CVE ids withdrawn: After some further analysis, we're going to withdraw some of these CVE name assignments. Some CVE ids withdrawn: After some further analysis, we're going to withdraw some of these CVE name assignments. Of the 11 issues Stefan reported recently we'll assign only two CVE names, under the policy that PHP scripts should be considered to execute with the permissions of the PHP interpreter. The others are not considered security issues: CAN-2004-1019 is assigned and covers three unserializer bugs: [03] etx/standard/var_unserializer.re - possible information leaks/overflows [06] etx/standard/var_unserializer.re - negative reference index array underflow [07] etx/standard/var_unserializer.re - reference to already freed array element and CAN-2004-1065 is assigned and covers parsing of exif images: [11] ext/exif/exif.c - exif_read_data() overflow on long sectionname I'll follow up with the complete patches for those sometime this week. To recap on the rest: [01] ext/shmop/shmop.c - shmop_write() out of bounds memory write access [02] ext/standard/pack.c - pack() integer overflows leading to heap bufferoverflow ext/standard/pack.c - unpack() integer underflow leading to heap info leak -> reqires malicious script: CAN-2004-1018 is WITHDRAWN [04] main/rfc1867.c - magic_quotes_gpc could lead to one level directory traversal -> no known direct security implications (no CVE name assigned) [05] ext/standard/string.c - addslashes (and therefore magic_quotes_gpc) does not properly escape \0 -> no known direct security implications, CAN-2004-1020 WITHDRAWN [08] TSRM/tsrm_virtual_cwd.c - virtual_popen() safe_mode_exec_dir bypass [09] TSRM/tsrm_virtual_cwd.c - virtual_file_ex() does not protect itself against malfunctional realpath() [10] main/safe_mode.c - Overlong filename fools security checks -> requires malicious script: CAN-2004-1063, CAN-2004-1064 both WITHDRAWN PHP releases 4.3.10 and 5.0.3 should be out wednesday. Given the amount of patching needed, I guess it makes sense to push to the release versions rather than patching. We should warn our PHP devs so that they can push that asap into our tree so that we can go to stable mode quickly. robbat2 please be ready to update as soon as it is released Wednesday. this appears to be public now (s. bug #74547) I'm making sure the new versions work quickly, ready to release them this afternoon. *** Bug 74547 has been marked as a duplicate of this bug. *** 4.3.10 and 5.0.3 are in CVS now. 4.3.10 is stable on x86 after my testing, and unstable on all other arches. 5.0.3 in only in unstable on all arches (ditto for the entire php-5 series). Thx for your swift response Robbin. Handling stable marking on bug #74547 and letting this stay closed. followups to bug 74547 |
