php vuln.

[troy]

Hola-

I know a lot of you folks run web servers with php... 

Summary: Malformed POST request leads to nastiness.  On x86, it seems to be
limited to "just" a crash of php. Other architectures may allow execution of
an attackers mean-n-nasty code. 

Upgrade available here: http://www.php.net/downloads.php

> Date: Mon, 22 Jul 2002 13:21:28 +0200
> From: e-matters Security <security at e-matters.de>
> To: bugtraq at securityfocus.com
> Cc: vulnwatch at vulnwatch.org
> Subject: Advisory 02/2002: PHP remote vulnerability
> Message-ID: <20020722112128.GB9191 at php.net>
> Reply-To: security at e-matters.de
> 
> 
>                            e-matters GmbH
>                           www.e-matters.de
> 
>                       -= Security  Advisory =-
> 
> 
> 
>      Advisory: Remote Compromise/DOS Vulnerability in PHP
>  Release Date: 2002/07/22
> Last Modified: 2002/07/22
>        Author: Stefan Esser [s.esser at e-matters.de]
> 
>   Application: PHP 4.2.0, 4.2.1
>      Severity: A vulnerability within the multipart/form-data handler
>                could allow remote compromise of the web server.
>          Risk: Critical
> Vendor Status: Patches Released.
>     Reference: http://security.e-matters.de/advisories/022002.html
> 
> 
> 
> Overview:
> 	
>    We have discovered a serious vulnerability within the default version 
>    of PHP. Depending on the processor architecture it may be possible for a 
>    remote attacker to either crash or compromise the web server. 
>  
> 	
> Details:
> 
>    PHP 4.2.0 introduced a completely rewritten multipart/form-data POST 
>    handler. While I was working on the code in my role as PHP developer
>    i found a bug within the way the mime headers are processed. 
>    A malformed POST request can trigger an error condition, that is not
>    correctly handled. Due to this bug it could happen that an uninit-
>    ialised struct gets appended to the linked list of mime headers.
>    When the lists gets cleaned or destroyed PHP tries to free the pointers
>    that are expected in the struct. Because of the lack of initialisation
>    those pointers contain stuff that was left on the stack by previous
>    function calls. 
> 
>    On the IA32 architecture (aka. x86) it is not possible to control what
>    will end up in the uninitialised struct because of the stack layout. All 
>    possible code paths leave illegal addresses within the struct and PHP
>    will crash when it tries to free them.
> 
>    Unfortunately the situation is absolutely different if you look on a
>    solaris sparc installation. Here it is possible for an attacker to free
>    chunks of memory that are full under his control. This is most probably
>    the case for several more non IA32 architectures.
> 
>    Please note that exploitability is not only limited to systems that are
>    running malloc()/free() implementations that are known to be vulnerable
>    to control structure overwrites. This is because the internal PHP memory
>    managment implements its own linked list system that can be used to
>    overwrite nearly arbitrary memory addresses.
>    
> 
> Proof of Concept:
> 
>    e-matters is not going to release the exploit for this vulnerability to
>    the public.
>    
> 
> Vendor Response:
> 
>    22th July 2002 - An updated version of PHP which fixes this 
>                     vulnerability was released and can be downloaded at:
> 
>                        http://www.php.net/downloads.php
> 
>                     The vendor announcement is available at:
> 
>                        http://www.php.net/release_4_2_2.php
> 
> 
> Recommendation:
> 
>    If you are running PHP 4.2.x you should upgrade as soon as possible,
>    especially if your server runs on a non IA32 CPU. If you cannot upgrade
>    for whatever reason the only way to workaround this, is to disable all
>    kinds of POST requests on your server.  
>    
>    
> GPG-Key:
> 
>    http://security.e-matters.de/gpg_key.asc
>     
>    pub  1024D/75E7AAD6 2002-02-26 e-matters GmbH - Securityteam
>    Key fingerprint = 43DD 843C FAB9 832A E5AB  CAEB 81F2 8110 75E7 AAD6
> 
> 
> Copyright 2002 Stefan Esser. All rights reserved.
> 
> 
>