Skip site navigation (1) Skip section navigation (2)

[Fwd: RE: Advisory 012002: PHP remote vulnerabilities (fwd)]

From: Justin Clift <justin(at)postgresql(dot)org>
To: PostgreSQL General Mailing List <pgsql-general(at)postgresql(dot)org>
Subject: [Fwd: RE: Advisory 012002: PHP remote vulnerabilities (fwd)]
Date: 2002-02-28 11:36:49
Message-ID: 3C7E1651.84736A6@postgresql.org (view raw or flat)
Thread:
Lists: pgsql-general
Hi everyone,

Just in case people haven't come across this advisory about PHP from
yesterday...

:-)

Regards and best wishes,

Justin Clift


-------- Original Message --------
Subject: RE: Advisory 012002: PHP remote vulnerabilities (fwd)
Date: Wed, 27 Feb 2002 17:17:28 -0800
From: "SoilentG" <soilentg(at)kovclan(dot)org>
Reply-To: modssl-users(at)modssl(dot)org
To: <modssl-users(at)modssl(dot)org>

Thanks.  One note.  I use php 4.0.6 and I had to set

file_uploads = 0

in order for it to take the value, setting it to "Off" showed "no value"
in
phpinfo();

Jeff

> -----Original Message-----
> From: owner-modssl-users(at)modssl(dot)org
> [mailto:owner-modssl-users(at)modssl(dot)org]On Behalf Of R. DuFresne
> Sent: Wednesday, February 27, 2002 4:28 PM
> To: modssl-users(at)modssl(dot)org
> Subject: Advisory 012002: PHP remote vulnerabilities (fwd)
>
>
>
> Considering the plethroa of php users on the list, and the fact many are
> perhaps not reading bugtraq:
>
> ---------- Forwarded message ----------
> From: security(at)e-matters(dot)de
> Subject: Advisory 012002: PHP remote vulnerabilities
> Date: Wed, 27 Feb 2002 12:30:56 +0100
> To: bugtraq(at)securityfocus(dot)com, vulnwatch(at)vulnwatch(dot)org
>
>                            e-matters GmbH
>                           www.e-matters.de
>
>                       -= Security  Advisory =-
>
>
>
>      Advisory: Multiple Remote Vulnerabilites within PHP's fileupload code
>  Release Date: 2002/02/27
> Last Modified: 2002/02/27
>        Author: Stefan Esser [s(dot)esser(at)e-matters(dot)de]
>
>   Application: PHP v3.10-v3.18, v4.0.1-v4.1.1
>      Severity: Several vulnerabilities in PHP's fileupload code allow
>                remote compromise
>          Risk: Critical
> Vendor Status: Patches Released
>     Reference: http://security.e-matters.de/advisories/012002.html
>
>
>
> Overview:
>
>    We found several flaws in the way PHP handles multipart/form-data POST
>    requests. Each of the flaws could allow an attacker to execute
> arbitrary
>    code on the victim's  system.
>
>
> Details:
>
>    PHP supports multipart/form-data POST requests (as described
> in RFC1867)
>    known as POST fileuploads. Unfourtunately there are several
> flaws in the
>    php_mime_split function that could be used by an attacker to execute
>    arbitrary code. During our research we found out that not only PHP4 but
>    also older versions from the PHP3 tree are vulnerable.
>
>
>    The following is a list of bugs we found:
>
>    PHP 3.10-3.18
>
>       - broken boundary check    (hard to exploit)
>       - arbitrary heap overflow  (easy exploitable)
>
>    PHP 4.0.1-4.0.3pl1
>
>       - broken boundary check    (hard to exploit)
>       - heap off by one          (easy exploitable)
>
>    PHP 4.0.2-4.0.5
>
>       - 2 broken boundary checks (one very easy and one hard to exploit)
>
>    PHP 4.0.6-4.0.7RC2
>
>       - broken boundary check    (very easy to exploit)
>
>    PHP 4.0.7RC3-4.1.1
>
>       - broken boundary check    (hard to exploit)
>
>
>    Finally I want to mention that most of these vulnerabilities are
>    exploitable only on linux or solaris. But the heap off by one is only
>    exploitable on x86 architecture and the arbitrary heap overflow in
>    PHP3 is exploitable on most OS and architectures. (This includes *BSD)
>
>    Users running PHP 4.2.0-dev from cvs are not vulnerable to any of the
>    described bugs because the fileupload code was completly rewritten for
>    the 4.2.0 branch.
>
>
> Proof of Concept:
>
>    e-matters is not going to release exploits for any of the discovered
>    vulnerabilities to the public.
>
>
> Vendor Response:
>
>    Because I am part of the php developer team there is not much I can
>    write here...
>
>    27th February 2002 - An updated version of php and the patch for
>                         these vulnerabilities are now available at:
>                         http://www.php.net/downloads.php
>
>
> Recommendation:
>
>    If you are running PHP 4.0.3 or above one way to workaround these
>    bugs is to disable the fileupload support within your php.ini
>    (file_uploads = Off) If you are running php as module keep in mind
>    to restart the webserver. Anyway you should better install the
>    fixed or a properly patched version to be safe.
>
>
> Sidenotice:
>
>    This advisory is so short because I don't want to give out more info
>    than is needed.
>
>    Users running the developer version of php (4.2.0-dev) are not
>    vulnerable to these bugs because the fileupload support was completly
>    rewritten for that branch.
>
>
> 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.
>
>
>
> ______________________________________________________________________
> Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
> User Support Mailing List                      modssl-users(at)modssl(dot)org
> Automated List Manager                            majordomo(at)modssl(dot)org
>

______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      modssl-users(at)modssl(dot)org
Automated List Manager                            majordomo(at)modssl(dot)org

pgsql-general by date

Next:From: tonyDate: 2002-02-28 12:00:49
Subject: Re: dates and encoding
Previous:From: Jan PoslusnyDate: 2002-02-28 09:18:26
Subject: Re: Drawing databases

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group