Stefan Esser has reported to vendor sec a number of information disclosure issues in PHP. 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 This issue should also affect RHEL2.1 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.
An additional issue has been added to this CVE id. = CAN-2004-1019 [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
Removing embargo
Hi, here is the URL to the Security Advisory by Stefan Esser: http://www.hardened-php.net/advisories/012004.txt There are a few issues: CAN-2004-1018, CAN-2004-1019, CAN-2004-1064. Some of them are critical, please check the advisory for the full info. Will the new 'php' package fix all the issues? Is there any ETA for it yet? Thanks.
The RHEL3 update is currently being worked on with the fixes for: CAN-2004-1065 - exif_read_data() overflow on long sectionname. CAN-2004-1018 - shmop_write() out of bounds memory write access. CAN-2004-1019 - possible information disclosure, double free etc CAN-2004-1018 - integer overflow/underflow in pack() and unpack() but not the fixes for: NA: CAN-2004-1020 - addslashes not escaping \0 correctly. (only applies to 4.3.9) NA: CAN-2004-1064 - arbitrary file access through path truncation. (only matters for threaded servers, we don't build PHP to support threads) The fix for CAN-2004-1063 (one of the safe_mode things) is non-obvious and looks risky, so is not included. RHEL2.1 will have a different subset of fixes, to be determined. The Security team rate the maximum severity of these issues as Important impact.
Can we get an unofficial people.redhat.com/PATH rpm link for a pre release build for local QA?
*Test* update packages are available (but unsupported) from: http://people.redhat.com/jorton/Taroon-php/.
Possibly related bugs: Bug 141135 Bug 142056 Bug 143101 (similar issues in 5.0 branch)
The PHP vulnerabilities are already being exploited in the wild: http://www.phpbb.com/phpBB/viewtopic.php?f=14&t=248046 This is really a critical issue for web hosting servers. Is there any ETA for new php package release? Thanks.
Updates for this issue are currently in QA and we hope to have them available today. Two of the reported PHP issues could have a significant impact, CAN-2004-1019, and CAN-2004-1065. CAN-2004-1019 covers the flaws in the deserialisation code. This can be an issue if you've got (your own or third party) PHP applications that use the unserialize function on untrusted user data. A proof of concept exploit as you mentioned exists that can dump memory out of some third party PHP webapp. CAN-2004-1065 covers flaws in the exif extension. If you have a PHP application that parses untrusted image files using the exif extension then this could lead to a stack overflow. It looks unlikely this could lead to code execution on Fedora Core w/Exec-shield. The remaining issues do not have a significant impact and would most likely require a malicious PHP script in order to exploit.
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-2004-687.html
Any estimate on the progress of the RHEL 2.1 update?