nginx 0day exploit for nginx + fastcgi PHP

[Ding Deng]

Igor Sysoev <igor at sysoev.ru> writes:

> On Fri, May 21, 2010 at 10:07:00AM -0700, Avleen Vig 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.
>
> I do not see why this is treated as nginx bug ?
> Why is anyone able at all to upload images to /scripts directory ?
> Why does PHP have cgi.fix_pathinfo option ?
> BTW, I'm just curious how does lighttpd resolve this issue ?

I suspect the 'broken-scriptfilename' option did the trick, and there's
also a 'Configuring PHP' section which explains the relationship between
'cgi.fix_pathinfo', PATH_INFO, PHP_SELF and 'broken-scriptfilename'.

http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs:ModFastCGI

more on 'cgi.fix_pathinfo':

http://bugs.php.net/31892

Igor, would 'fastcgi_split_path_info' help on this?


> Also instead of
>
> if ( $fastcgi_script_name ~ \..*\/.*php ) {
>     return 403;
> }
>
> it should be worked around as
>
> location ~ \..*/.*\.php$ {
>     return 403;
> }
>
> location ~ \.php$ {
>     return 403;
> }