

New PHP Vulnerability:?-s may expose source code for mod_cgi - ecaron
http://www.php.net/archive/2012.php#id2012-05-03-1

======
ComputerGuru
This vulnerability is about as bad as it gets, and my heart stopped while I
was reading the intro (it's so trivially simple to compromise a site).

Then I reached this sentence, which I felt needed to be bolded and underlined:

 _A large number of sites run PHP as either an Apache module through mod_php
or using php-fpm under nginx. Neither of these setups are vulnerable to this._

<insert immense sigh of relief>. Thank God.

That said, some blackhats are going to be really sore that a backdoor that's
been wide open for "at least 8 years" is finally being closed.

~~~
ecaron
You're right, my title was a bit sensational. I softened it a bit by appended
mod_cgi. I think it is very telling that the PHP core recognizes that the
people using mod_cgi probably can't upgrade so they're offering a .htaccess
adjustment - very commendable.

~~~
kijin
Well, after all, PHP is all about backwards compatibility.

------
caf
From the commit that introduced this bug:

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

Perfectly illustrating the utility of well-chosen comments in code.

~~~
rmccue
In addition, it illustrates the utility of well-written commit messages with
judicious use of the blame utility.

------
trevorg75
Here's a fun fact...if you try this trick on <http://facebook.com/> you get
the following source code

<?php

include_once
'[https://www.facebook.com/careers/department?dept=engineering...](https://www.facebook.com/careers/department?dept=engineering&req=a2KA0000000Lt8LMAS);

~~~
mmcnickle
Clever. I wonder if they have a tradition of having exploit easter eggs like
this?

------
vog
From the article:

 _> [...] we had a bug in our bug system [...] causing this issue to go public
before we had time to test solutions to the level we would like._

Ouch.

~~~
cheald
So we know about this issue because the bug for the disclosure vulnerability
was vulnerable to disclosure because of a bug.

------
Palomides
<http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/> has some more
info, including the fact that they first reported it to the PHP devs in the
middle of January.

------
endijs
From Twitter: Stefan Esser ‏ @i0n1c The security emergency release to fix the
PHP CGI RCE (that was tested for days...) does not fix anything at all.

~~~
0x0
Here is the fix that was applied:

[https://github.com/php/php-
src/commit/55869a95ab75c0eb99c572...](https://github.com/php/php-
src/commit/55869a95ab75c0eb99c57201bfeccaef57e0d36d)

If the first char in the query string is "-" and the query string also
contains "=", it skips cmdline argument option parsing.

Maybe it is possible to construct a string not starting with "-", not
containing "=", but containing a "+" followed by "-options" further out?

~~~
sirclueless
No, the problem is that they check the decoded query string for `=` signs, but
Apache checks the raw query string. If you pass an encoded `=` anywhere in the
query string then you can bypass the fix.

------
randomdrake
1) It's not new.

2) Running PHP as regular CGI (not FCGI) is a very dated practice so the
amount of implementations that are vulnerable is probably limited.

------
wanderr
As has been mentioned, using CGI for php is quite outdated so it probably
doesn't impact that many sites, that said this sort of vulnerability is
exactly why you should put all but the minimum front controller PHP in a
folder that's outside of the public folder your site is being served from.

~~~
marklindhout
Absolutely not. Lighttpd and Nginx both use it, and have recently picked up a
lot of popularity because of it.

It maybe an old mechanism, but it is fast, which is worth something these days
:)

~~~
gregbair
Those generally use FastCGI, which again, is not vulnerable.

------
richbradshaw
8 years!!!! I wonder how many people knew about this already...

On the other hand, this does make me feel better about my own code!

------
nthitz
Wow, it's pretty scary that a vulnerability as simple as this has been around
for 8 years!

~~~
fusiongyro
Yeah, but nobody's run PHP in this silly CGI configuration for 10 years.

~~~
bleusink
I wouldn't be so sure: <http://wiki.dreamhost.com/Php#PHP_on_DreamHost>

~~~
maratd
That's horrible! I would never use a host that relied on CGI for anything.
There's a reason they came out with FastCGI.

~~~
devicenull
FastCGI makes little to no sense on shared web hosting machines. With FastCGI,
each user on the machine needs at least one long-running process to handle
requests. This is a waste when you consider that large numbers of the sites
may be idle 99% of the time. With CGI, you only have PHP processes running
when they are actually handling requests, it's really a much better solution
for shared hosting.

~~~
mikey_p
With PHP 5.3.9 or 5.3.10 and php-fpm a new method of process management called
ondemand was introduced that handles this use care very well. With a super
short idle timeout (a few seconds) this could work very well for shared
hosting, but I doubt there are many folks using it since it does still require
the process manager to stay running in order to start the workers (this makes
it hard to have user configurable php.ini settings since it would require
restarting the master).

See <http://www.php.net/manual/en/install.fpm.configuration.php> under 'pool'
group and the 'pm' setting.

~~~
rmccue
You can send a signal to php-fpm to reload configuration without restarting
(at least, the way I read it). My /etc/init.d/php-fpm has "reload" with `kill
-USR2 $PHP_PID`

------
dawkins
"we had a bug in our bug system that toggled the private flag of a bug report
to public on a comment to the bug report causing this issue to go public
before we had time to test solutions to the level we would like" Thats having
a really bad day!

------
TazeTSchnitzel
Huh. I'd used that method of passing in parameters, mistakenly thinking it was
the correct way to get a query string.

Then I asked on SO and found out I was doing things horribly, horribly wrong.

~~~
yahelc
How would that have worked?

~~~
TazeTSchnitzel

        http://example.com/cgi/mything?stuff
    

Results in apache calling:

    
    
        /home/ajf/cgi/mything stuff

------
jsnrkd
Does anyone have an example site to see this in action?

~~~
yahelc
I'd thought you could find some with this Google search, but I haven't gotten
any to work.

[https://www.google.com/search?q=inurl:%22cgi-
bin%22+inurl:ph...](https://www.google.com/search?q=inurl:%22cgi-
bin%22+inurl:php&hl=en&safe=off&prmd=imvns&ei=9fSiT9nlBomI6AG50N35CA&start=10&sa=N&biw=1015&bih=557)

~~~
jgeralnik
Using that search and clicking through a few pages I found this:
<http://support.webroot.com/app/answers/detail/a_id/1761> which is susceptible
to this vulnerability.

------
gouranga
That's hilariously shitty.

Although to be honest I doubt it's going to affect anyone as I reckon 99%+ are
on mod_php.

------
micahshell
Their is a fix here.

<http://pastebin.com/87sfaYL1>

------
EricR23
To my knowledge, this vulnerability is anything but new. It's been around for
years.

------
rorrr
I don't think any major site uses mod_cgi.

------
NaturalDoc
what? a new php vulnerability? havent heard of one of these for a few hours!!

~~~
soc88
I don't understand why this is downvoted, considering that the bugfixes don't
work.

~~~
EvilTerran
Perhaps because vacuous, pandering snark adds absolutely no value to the
conversation?

