[UNIX] PHP unserialize() Array Creation Integer Overflow

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html

- - - - - - - - -



PHP unserialize() Array Creation Integer Overflow
------------------------------------------------------------------------


SUMMARY

" <http://www.php.net> PHP is a widely-used general-purpose scripting
language that is especially suited for Web development and can be embedded
into HTML."

The PHP 5 branch of the PHP source code lacks the protection against
possible integer overflows inside ecalloc() that is present in the PHP 4
branch and also for several years part of our Hardening-Patch and our new
Suhosin-Patch.

It was discovered that such an integer overflow can be triggered when user
input is passed to the unserialize() function. Earlier vulnerabilities in
PHP's unserialize() that were also discovered by one of our audits in
December 2004 are unrelated to the newly discovered flaw, but they have
shown, that the unserialize() function is exposed to user-input in many
popular PHP applications. Examples for applications that use the content
of COOKIE variables with unserialize() are phpBB and Serendipity.

The successful exploitation of this integer overflow will result in
arbitrary code execution.

DETAILS

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@xxxxxxx, 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>
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>
http://www.hardened-php.net/suhosin/index.html


ADDITIONAL INFORMATION

The information has been provided by <mailto:sesser@xxxxxxxxxxxxxxxx>
Stefan Esser.
The original article can be found at:
<http://www.hardened-php.net/advisory_092006.133.html>
http://www.hardened-php.net/advisory_092006.133.html



========================================


This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@xxxxxxxxxxxxxx
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@xxxxxxxxxxxxxx


====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

Relevant Pages