Message-ID: <20061009065107.GA8244@hardened-php.net>
Date: Mon, 9 Oct 2006 08:51:07 +0200
From: Stefan Esser <sesser@...dened-php.net>
To: bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk
Cc: red@...sec.de
Subject: Advisory 09/2006: PHP unserialize() Array
	Creation Integer Overflow

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


                        Hardened-PHP Project
                        www.hardened-php.net

                      -= Security  Advisory =-


     Advisory: PHP unserialize() Array Creation Integer Overflow
 Release Date: 2006/10/09
Last Modified: 2006/10/09
       Author: Stefan Esser [sesser@...dened-php.net]

  Application: PHP 5 <= 5.1.6, PHP 4 < 4.3.0
 Not affected: PHP 4 >= 4.3.0,
               PHP with Hardening-Patch,
               PHP with Suhosin-Patch
     Severity: User-input passed to the unserialize() function might 
               trigger an integer overflow in array creation that 
               might result in remote code execution
         Risk: Critical
Vendor Status: Fixed in CVS, no security update planned, wait for PHP 5.2.0
   References: http://www.hardened-php.net/advisory_092006.133.html


Overview:

   Quote from 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:

   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.


Proof of Concept:

   The Hardened-PHP Project will release a proof of concept exploit
   for this vulnerability after the release of PHP 5.2.0 has happened
   and a few weeks have passed.


Disclosure Timeline:

   30. September 2006 - Notified security@....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


CVE Information:

   The Common Vulnerabilities and Exposures project (cve.mitre.org) has
   assigned the name CVE-2006-4812 to this vulnerability.
               

GPG-Key:

   http://www.hardened-php.net/hardened-php-signature-key.asc

   pub  1024D/0A864AA1 2004-04-17 Hardened-PHP Signature Key
   Key fingerprint = 066F A6D0 E57E 9936 9082  7E52 4439 14CC 0A86 4AA1


Copyright 2006 Stefan Esser. All rights reserved.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFKfzkRDkUzAqGSqERAkMuAKCw+OadmbMHtdRV9A3kh3o81nbaNACggDuD
K5E+jNHI1LbxybPhlsBtWo8=
=6AC+
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists