Slashdot Mirror

← Back to Stories (view on slashdot.org)

Recently Exposed PHP Hole's Official Fix Ineffective

Posted by timothy on from the considered-busted dept.

wiredmikey writes "On Wednesday, a remote code execution vulnerability in PHP was accidentally exposed to the Web, prompting fears that it may be used to target vulnerable websites on a massive scale. The bug itself was traced back to 2004, and came to light during a recent CTF competition. 'When PHP is used in a CGI-based setup (such as Apache's mod_cgid), the php-cgi receives a processed query string parameter as command line arguments which allows command-line switches, such as -s, -d or -c to be passed to the php-cgi binary, which can be exploited to disclose source code and obtain arbitrary code execution,' a CERT advisory explains. PHP developers pushed a fix for the flaw, resulting in the release of PHP 5.3.12 and 5.4.2, but as it turns out it didn't actually remove the vulnerability."

6 of 240 comments (clear)

  1. Actual Details... by Anonymous Coward · · Score: 5, Informative

    Available from the source, not information week.

    The info I was looking for:
    - FastCGI installations are not vulnerable
    - can only be exploited if the HTTP server follows a fairly obscure part of the CGI spec. Apache does this, but many other servers do not.

  2. Training wheels without the bike by A+beautiful+mind · · Score: 5, Informative

    I think this short snippet from Rasmus is priceless:

    The point of the question here is if anybody remembers why we decided not
    to parse command line args for the cgi version? I could easily see it
    being useful to be able to write a cgi script like:

        #!/usr/local/bin/php-cgi -d include_path=/path

    and have it work both from the command line and from a web context.

    As far as I can tell this wouldn't conflict with anything, but somebody at
    some point must have had a reason for disallowing this.

    Yeah, passing arguments with full shell expansion to the bloody binary from the unsecure web sounds like a brilliant idea! Who would want to disallow that?!

    It was pretty funny so far, but then I've seen this:

    13-01: Vulnerability discovered, used to pwn Nullcon Hackim 2012 scoreboard
    13-01: We discuss the issue with Nullcon admins, find out it is a php 0day
    17-01: We contact security@php.net with a full report and a suggested patch
    01-02: We ask PHP to confirm receipt, state our intent to hand off the vulnerability to CERT if progress is not made
    01-02: PHP forwards vulnerability report to PHP CGI maintainer
    23-02: CERT acknowledges receipt of vulnerability and attempts to contact PHP.
    05-04: We ask CERT for a status update
    05-04: CERT responds saying that PHP is still working on a fix
    20-04: We ask CERT to proceed with disclosure unless a patch is imminent
    26-04: CERT prepares draft advisory.
    02-05: CERT notifies us that PHP is testing a patch and would like more time. we agree.
    03-05: Someone posts a mirror of the internal PHP bug to reddit /r/netsec /r/opensource and /r/technology. It was apparently accidentaly marked public.

    The PHP security people sat on this 0day remote code exploit for four months, ignoring multiple attempts to get them to fix this serious vulnerability. That makes me feel angry, sometimes incompetence is just not funny anymore.

    --
    It takes a man to suffer ignorance and smile
    Be yourself no matter what they say
  3. Re:Cm'on by nickdc · · Score: 5, Interesting

    The answer is Facebook, and I got a job by using this bug against them! see?

  4. Re:And by drunkennewfiemidget · · Score: 5, Interesting

    > No licensing
    Wrong

    > stable
    This news post is proof that's wrong.

    > great track record
    Wrong.

    > flexable
    About as flexible as your spelling.

    > modules for everything
    This is true. AND THEYRE ALL PART OF THE CORE API! ImageMagick, MySQL (THREE TIMES!), Curl, etc .. all in the core API.

    PHP is a fucking disgrace and a blight on the world and needs to die a fiery death.

    (Spend a few minutes reading the url I linked above at veekun.com for a wonderful break won on why PHP is a heinous pile of horseshit.)

  5. Re:And by Richard_at_work · · Score: 5, Insightful

    Out of interest, what does the "great track record" refer to? The security has historically been consistently horrific, the performance has historically been consistently horrific, the consistency of the language has been consistently horrific, the development of the language has been consistently horrific...

    I do miss the documentation, now that was awesome. But I don't miss the rest of it.

  6. Re:And by Anonymous Coward · · Score: 5, Funny

    Out of interest, what does the "great track record" refer to? The security has historically been consistently horrific, the performance has historically been consistently horrific, the consistency of the language has been consistently horrific, the development of the language has been consistently horrific...

    They do have a great track record at being consistently horrific...