|
|
|
|
| |
Credit:
The information has been provided by Stefan Esser.
The original article can be found at: http://www.hardened-php.net/advisory_092006.133.html
|
| |
Vulnerable Systems:
* PHP 5 version 5.1.6 and prior
* PHP 4 version prior to 4.3.0
Immune Systems:
* PHP 4 version 4.3.0 and newer
Details:
Several years ago when integer overflows inside the calloc() function-family became popular in the security industry, many function libraries that contained similar allocation functions were hardened against the possible multiplication overflow.
The ecalloc() function used in the Zend Engine 1 was one of the functions that were hardened against this kind of attack. Unfortunately the PHP developers never bothered merging this protection into the code of the Zend Engine 2, which powers PHP 5.
However when Hardened-PHP was created by us in 2004 a similar protection of ecalloc() was added to our patch. Therefore our users are safe from the problem described here.
unserialize() is a PHP function that allows deserialisation of previously serialised PHP variables. Many applications use it to store PHP variables in an easy accessible data format. Some of them even put serialised strings into COOKIEs and later unserialize() them again.
Unfortunately passing user-input to unserialize() is a bad idea because it also supports the deserialisation of objects, which might influence the application. Additionally it is trivial to crash PHP with a large amount of nested arrays.
Furthermore we discovered that storing a large value for the number of array elements into the serialised string will trigger an integer overflow inside ecalloc(), resulting in the allocation of 0 bytes (plus the Zend Memory Manager management headers).
When this happens unserialize() will continue working with a to small bucket array. When the string is parsed for the array elements the HashTable functions will operate on memory not allocated for this purpose. This can lead to several different memory corruption attacks.
A carefully crafted string can use this to execute arbitrary code. In our proof of concept exploit this is achieved by storing a HashTable with our own destructor into the PHP array. When the PHP variable is destroyed this will result in the execution of our shellcode.
Note: In general this kind of attack on HashTable destructors is impossible when Hardening-Patch or Suhosin-Patch are installed because both detect modification of HashTable destructors.
Note: In general we dislike to release advisories while there are no official fixed versions available, but the fact that Linux distributions already are shipping patched versions and that the PHP CVS contains an explicit commit message we believe it is important all parties about unserialize(). It is not really a problem to find out with a few grep commands that unserialize() is allowing dangerous ecalloc() calls.
Disclosure Timeline:
30. September 2006 - Notified security@php.net, vendor-sec
30. September 2006 - Patch was committed to PHP CVS
05. October 2006 - Redhat, Mandriva release PHP updates
06. October 2006 - PHP security updates in media
09. October 2006 - Public Disclosure
Recommendation:
It is strongly recommended to patch your version of PHP with the following patch until php.net is providing updates. http://www.hardened-php.net/files/CVE-2006-4812.patch
As usual we very strongly recommend to install our Suhosin-Patch and the Suhosin Extension. Once again it was proved, that our patch protects users of PHP against unknown flaws within PHP. Users of our patch have been protected against this flaw for about 2 years now.
Our Suhosin extension on the other hand supports transparent cookie encryption. When TCE is activated, which is the default setting, and the encryption key is set it is not possible for an external attacker to exploit the unserialize() flaws in our examples: phpBB and Serendipity.
Grab your copy and more information at: http://www.hardened-php.net/suhosin/index.html
|
|
|
|
|
