New PHP Vulnerability:?-s may expose source code for mod_cgi
php.net
php.net
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.
The vulnerability 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.
From: http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/
It took me a bit to figure out _how_, but it's nothing obscure or difficult. In fact it relies on _other_ bozotic PHP behavior to work!
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.
<?php
include_once 'https://www.facebook.com/careers/department?dept=engineering...;
> [...] 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.
https://github.com/php/php-src/commit/55869a95ab75c0eb99c572...
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?
2) Running PHP as regular CGI (not FCGI) is a very dated practice so the amount of implementations that are vulnerable is probably limited.
It maybe an old mechanism, but it is fast, which is worth something these days :)
On the other hand, this does make me feel better about my own code!
If that space isn't needed, then the cost is nil (it takes the same amount of power to store a 1 as a 0; the real power cost is in moving data in and out of memory, not in storing it).
If the space is needed, then the idle process can be swapped out to disk. So again, no practical cost.
FastCGI may not be the best solution, but CGI is not an improvement (the overhead of starting a new runtime to handle every request will introduce a lot of latency, which will be especially noticeable on pages that make a lot of asynchronous requests).
If the FastCGI process is swapped out, does it still have a performance benefit?
I'm inclined to say yes, it would still have a benefit. My thoughts:
- Swapping the FastCGI process back in shouldn't be any worse than loading a CGI process cold and initializing it (disk caching will probably be no help to CGI here: with so little free memory, the cache will be small or nonexistent and aggressively purged);
- Once swapped in, the FastCGI process will be able to handle multiple requests in less time and less memory than it would take just to start the many CGI processes necessary to do the same work.
Also, if the performance of your server is an issue, your FastCGI process should never be in a situation where it would be swapped out. You need to add more memory, and/or reduce the other loads on your server.
See http://www.php.net/manual/en/install.fpm.configuration.php under 'pool' group and the 'pm' setting.
Then I asked on SO and found out I was doing things horribly, horribly wrong.
http://example.com/cgi/mything?stuff
/home/ajf/cgi/mything stuffwww.ptecwebdev.com?-s
https://www.google.com/search?q=inurl:%22cgi-bin%22+inurl:ph...
Although to be honest I doubt it's going to affect anyone as I reckon 99%+ are on mod_php.