nginx 0day exploit for nginx + fastcgi PHP

[Michael Shadle]

I believe that it will address the issue. Should give it a shot. I  
have some scripts that I had to use it on even though I have  
cgi.fix_pathinfo=1



On May 22, 2010, at 6:23 AM, Ding Deng <ding.deng at gmail.com> wrote:

> 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;
>> }
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://nginx.org/mailman/listinfo/nginx