Recently Exposed PHP Hole's Official Fix Ineffective

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

Actual Details...

[Anonymous Coward]

Available from the source [eindbazen.net], 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.

Training wheels without the bike

[A beautiful mind]

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 [e-mail] 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.

false - PHP has various licensing

[rubycodez]

http://php.net/license/index.php [php.net] PHP has a license which must be respected by law. Certain parts of it have various licenses too. These are Open Source licenses, and as such have many benefits. Nevertheless, there are licenses.

Re:Cm'on

[19thNervousBreakdown]

Huh, the practice is even recommended by Zend [zend.com]. Isn't PHP great, where a closing tag is a vector for bugs?

Re:You shouldn't. Nobody should.

[Just Some Guy]

Prepared statements [php.net]. Even PHP supports them, although they don't emphasize that fact enough (such as by causing calls to mysql_query to segfault, or ideally make the server hosting it catch on fire).

I say that in humor, but I'm actually dead serious about always using prepared statements - in any language - over directly executing concatenated query strings. It's one thing if you're the person writing the DB interface library that everything runs through and the database itself doesn't provide some kind of facility for helping you. In that case, you go to heroic lengths to test, test, test that your library is bulletproof. But most people aren't writing client libraries; they're writing apps that use them. Those people should never be manually building query strings. Not "well, not usually but..." or "there are some situations where...". No there aren't. Don't do that or let anyone else around you do it, either.

Re:You shouldn't. Nobody should.

[Anonymous Coward]

Which is, in fact, available in PHP. Any PHP programmer not entirely retarded knows to use prepared statements. The docs Just Some Guy posted are from the bloody ancient mysql library which is hardly in use any more. They're of course still available, for backwards compatibility, so obviously the documentation has to be too.

Note that I'm not defending PHP, I find it a complete mess. But ragging on for the wrong reasons is just dumb and won't convince anyone. Now, if you were to criticise the insane inconsistency in the standard library--such as never being able to decide on camel case or underscores, the consistent inconsistency of needle/haystack parameter ordering, and so on and so forth--or the fucked up automatic type casts and equality operators, then you'd be making a point.