Become a fan of Slashdot on Facebook


Forgot your password?
Bug PHP Programming Security

Recently Exposed PHP Hole's Official Fix Ineffective 240

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."
This discussion has been archived. No new comments can be posted.

Recently Exposed PHP Hole's Official Fix Ineffective

Comments Filter:
  • by DieByWire ( 744043 ) on Saturday May 05, 2012 @10:43AM (#39901367)
    PHP: Pretty Hard to Protect.
  • Actual Details... (Score:5, Informative)

    by Anonymous Coward on Saturday May 05, 2012 @10:48AM (#39901405)

    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.

  • by A beautiful mind ( 821714 ) on Saturday May 05, 2012 @11:03AM (#39901471)

    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 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.

  • by colfer ( 619105 ) on Saturday May 05, 2012 @11:21AM (#39901557)

    My web host pushed this patch into user htaccess for those users clueful enough to be running php as cgi:
        RewriteEngine on
        RewriteCond %{QUERY_STRING} ^[^=]*$
        RewriteCond %{QUERY_STRING} %2d|- [NC]
        RewriteRule .? - [F,L]

    Shared hosting at this ISP, a well-regarded one, disables normal PHP's ability to write files unless you open up directory permissions (777). Last time I checked, other users could also read files unless you used 600. Two problems, hence, they support php-cgiwrap if you know enough to want it.

    Running PHP as cgi is the only reasonable choice at shared hosts like this, with a robust, but essentially legacy, Linux structure.

    Seems crazy. CloudLinux does segregate users (nothing to do with a cloud, by the way), and other Linuxes can be protected various ways (FutureQuest has done shared hosting right for a long time.)

    • also it seems that lighttpd+php-fastcgi is not vulnerable.

"Let every man teach his son, teach his daughter, that labor is honorable." -- Robert G. Ingersoll