nginx 0day exploit for nginx + fastcgi PHP

[Michael Shadle]

Question is, what functionality is lost by changing

cgi.fix_pathinfo = 0

Looks like the other workaround is something like this:

if ( $fastcgi_script_name ~ \..*\/.*php ) {
 return 403;
}

Which i basically saying what exactly? If there is a period and slash
somewhere prior to the last "filename" to return a 403?

Ideally while this is being thought out it would be cool to fix the
common "no input file specified" issue that a lot of people have -
have it return a 404 instead. Not sure if it's a simple php.ini change
(perhaps the path info?) or change fastcgi_param REDIRECT_STATUS 200?


On Fri, May 21, 2010 at 10:07 AM, Avleen Vig <avleen at gmail.com> wrote:
> This is currently doing the rounds, so I thought it pertinent to post
> it here too.
>
> http://www.webhostingtalk.com/showthread.php?p=6807475#post6807475
>
> I don't know what nginx should do to fix this, but there are two
> workarounds given.
> If you allow file uploads (especially things like images) and use PHP
> FastCGI in the back end, you should take a loot at this now.
> The exploit allows for any arbitrary file which is uploaded, to be
> executed as PHP.
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://nginx.org/mailman/listinfo/nginx
>