Results 1 to 4 of 4

Thread: Vulnerability: PHP Multiple Remote vulerability in fileupload code

  1. #1
    Fastest Thing Alive s0nIc's Avatar
    Join Date
    Sep 2001
    Location
    Sydney
    Posts
    1,584

    Exclamation Vulnerability: PHP Multiple Remote vulerability in fileupload code

    Multiple Remote Vulnerabilites within PHP's fileupload code

    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

    Source:
    http://www.xatrix.org/modules.php?op...thread&order=1

  2. #2
    Senior Member
    Join Date
    Nov 2001
    Posts
    119
    the only thing that doesn\'t change is everything will always change.

  3. #3
    Fastest Thing Alive s0nIc's Avatar
    Join Date
    Sep 2001
    Location
    Sydney
    Posts
    1,584
    hehe yeah.. preety much. though our sources are different...

    i wonder how many people actually bothered reading these warnings.. especially that PhP is getting popular..

  4. #4
    Senior Member
    Join Date
    Nov 2001
    Posts
    119
    yep that's true but you know the most ppl react after **** happens... and then they are wondering how can that happen or i've never heard about from that..

    reading this stuff is pretty important!!
    another good example is:how many sysadmin have ever read security-relevant rfc's ??\

    i don't like to know this ....
    the only thing that doesn\'t change is everything will always change.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •