1. "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 `script.sh` beginning with `#!/bin/sh` is 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.
2. 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_INFO` environment 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
environment variables,
and one of them (`REDIRECT_STATUS`)
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.
