nginx 0day exploit for nginx + fastcgi PHP

Michael Shadle mike503 at gmail.com
Fri May 21 21:48:19 MSD 2010


On Fri, May 21, 2010 at 10:33 AM, Igor Sysoev <igor at sysoev.ru> wrote:

> I do not see why this is treated as nginx bug ?
> Why is anyone able at all to upload images to /scripts directory ?

It's not really a bug, like he said. However it is a configuration
method that almost everyone uses for nginx.

This is probably why "cgi-bin" was such a standard for so many years.
"Only execute things in this directory!" but this gets around that due
to the looser configuration most people have in nginx.

> Why does PHP have cgi.fix_pathinfo option ?

I want to figure this out too. Once I can replicate this issue I'm
going to disable it, see if it gets fixed, and then see if any other
scripts are messed up by disabling that.

from php.net:

Provides real PATH_INFO/PATH_TRANSLATED support for CGI. PHP's
previous behaviour was to set PATH_TRANSLATED to SCRIPT_FILENAME, and
to not grok what PATH_INFO is. For more information on PATH_INFO, see
the cgi specs. Setting this to 1 will cause PHP CGI to fix it's paths
to conform to the spec. A setting of zero causes PHP to behave as
before. Default is zero. You should fix your scripts to use
SCRIPT_FILENAME rather than PATH_TRANSLATED.

I think lighttpd might not be touched because it doesn't use regex
configurations to pass things to the PHP interpreter as "trusted" code
to execute. It determines the real file internally and then parses the
extension (is how I would think it works)



More information about the nginx mailing list