I’m the author of the eris HTTPd, a small web server intended for use on embedded Linux devices with low RAM and low storage. I’ve used other web servers (boa, mathopd, thttpd, etc.) for years, and this problem has been present for as long as I can remember. A recent gripe post about PHP inspired me to document it.
Let’s say I’m using something that isn’t Apache, and I need to run some PHP code. PHP comes with a CGI variant, so I’ll use that:
#! /usr/bin/php-cgi <?php phpinfo(); ?>
When run from the command-line, this does exactly what I expect. Superb! When I try it from a browser, though, I get:
Unable to load the webpage because the server sent no data.
Well that’s puzzling. So I do my standard thing, wrapping it with something to dump stderr to stdout.
#! /bin/sh echo "Content-type: text/plain" echo exec foo.php.cgi 2>&1
Now I get this (reformatted for narrow displays):
<b>Security Alert!</b> The PHP CGI cannot be accessed directly. <p>This PHP CGI binary was compiled with force-cgi-redirect enabled. This means that a page will only be served up if the REDIRECT_STATUS CGI variable is set, e.g. via an Apache Action directive.</p> <p>For more information as to <i>why</i> this behaviour exists, see the <a href="http://php.net/security.cgi-bin">manual page for CGI security</a>.</p> <p>For more information about changing this behaviour or re-enabling this webserver, consult the installation file that came with this distribution, or visit <a href="http://php.net/install.windows">the manual page</a>.</p>
It’s writing out HTML, sort of: I mean, the first paragraph doesn’t have
P tags, but whatever.
So clearly they intend me to see it from a browser.
I mean, the interpreter binary is called
php-cgi, after all.
And yet, they’re not actually writing out a CGI header,
so the web server thinks it’s a broken script and dies.
So maybe they meant me to view this from the command-line;
except the only way to get this error is to run it as CGI.
PHP is asking me to set the
and telling me that this is somehow a security concern.
It’s interesting how Python, Perl, and Lua don’t think the lack of this variable is a security problem.
A quick Google search tells me this is a non-standard CGI variable that Apache sets. But I’m not using Apache, otherwise I’d just use mod_php. Why are you making me set this, PHP?
What I thought would fix it
#! /bin/sh echo "Content-type: text/plain" echo REDIRECT_STATUS=1 export REDIRECT_STATUS exec foo.php.cgi 2>&1
Now I get this:
Status: 404 Not Found X-Powered-By: PHP/5.3.3-7+squeeze15 Content-type: text/html No input file specified.
However, it continues to run just fine from the command-line.
404 means “file not found”.
Which is very strange, because clearly the file was found,
given that PHP has sent its “X-Powered-By” header.
If it couldn’t find the file, it wouldn’t have known enough to start php-cgi.
And, remember, this all works fine from the command line.
Not to mention Python, Perl, Lua, and even the lowly Awk and Bourne shell,
have no trouble finding their input file when run as a CGI with the shebang (
as the first line.
What actually fixed it
After nearly a full day trying to chase this cryptic message down in web searches, I landed on a PHP bug open since 2004: PHP CGI depends on non-standard SCRIPT_FILENAME. Included in the comments on this ancient but still unresolved bug is a now-broken link to a wrapper which proports to fix the problem.
So the ultimate fix to make
php-cgi actually run like a CGI is to wrap it
with a second CGI that convinces PHP that I really meant it:
#! /bin/sh REDIRECT_STATUS=1 export REDIRECT_STATUS SCRIPT_FILENAME=$(pwd)/foo.php.cgi export SCRIPT_FILENAME exec $SCRIPT_FILENAME 2>&1
If I have multiple PHP CGIs, I must wrap each one. Or just give up and install Apache, which is, I’m sure, the path taken by most system administrators who haven’t written their own web server.
Why does PHP do this?
I have skimmed the URL that they asked me to. They list two points:
“Interpreters open and execute the file specified as the first argument on the command line.” This is true, it’s how shebangs work (a file
#!/bin/shis magically transformed to
["/bin/sh", "script.sh"]). It’s how Python and Perl launch. I don’t get the exploit path here, unless there’s some horrible way to misconfigure Apache to do the wrong thing with scripts.
If you put the php interpreter under your web server’s document root (where files are served from), and then use it to load up php scripts using the
PATH_INFOenvironment variable which is specified by the end user, then PHP will dutifully serve up every document on your machine.
If you don’t get it, (I didn’t either), what they mean is that some sysadmins honestly want the following URL to work:
This is such a terrible way to do things that it took me half an hour to even understand what they were describing. It’s analagous to putting your shell in
/var/www/cgi-bin and then asking the browser (which, remember, the end user can make do whatever they please) to pass the path to your shell script in as part of the URL.
These are both just awful, terrible,
hideous ways to set up a web server.
But apparently people do it anyway,
and apparently the PHP developers felt like it was their job
to allow this setup and still try to prevent
some of the security nightmares it entails.
Their solution: introduce dependencies on two Apache-specific
and one of them (
isn’t even checked further than “is this set to anything at all”.
And that, dear reader, is why you must fake out PHP in order to get it to behave like every other CGI ever written.