Possible widespread PHP configuration issue - security risk

[Ed W]

  On 27/08/2010 20:06, Michael Shadle wrote:
> Initial testing shows:
>
> cgi.fix_pathinfo = 0
>
> and Igor's suggestion:
>
> location ~ ^(?<script>.+\.php)(?<path_info>.*)$ {
>      fastcgi_pass 127.0.0.1:11000;
>      fastcgi_param   SCRIPT_FILENAME  $document_root$script;
>      fastcgi_param   PATH_INFO        $path_info;
>      include fastcgi_params;
> }
>
> To be working properly. I need to check out PATH_INFO using old style
> and new style, make sure it still reports the expected behavior for
> PHP scripts (PATH_INFO, PHP_SELF, all that jazz)


I will believe you that this works, but it seems incredibly subtle and I 
for one don't quite understand why it's working?

My point is only that we need to document how/why this is the solution 
or users will deviate (innocently) and re-introduce the problem


Please, please also lets have the final solution also include an example 
of how to efficiently *exclude* a certain directory. A good proportion 
of apps that I have seen, ship with example Apache configurations that 
do exactly this.

The suggestion was adding an excluded location:

     location ^~/images/  {
         # just handle as static, don't consult regexps
     }

However, the issue I see here is that the user then needs to 
specifically configure how that location should be handled, rather than 
it being an *exclusion* to the original location

Can we work excluded locations into the regexp (negative lookahead 
supported?):

	location ~ ^(?!/images/)(?<script>.+\.php)(?<path_info>.*)$ {


The justification for excluding specific locations from the PHP 
interpretor is that *most* applications don't encourage uploaded 
executable cgi scripts and better apps are going to ship with a 
recommendation to disable script execution in the upload directory.  
Actually the situation is worse on Apache because there are so many ways 
to trick the interpreter to run files.  However, it's seems to be such 
standard practice on Apache that it seems prudent to include it in our 
standardised solution?

Lots of justifications for this via google:
     
http://www.google.co.uk/search?hl=en&q=disable+php+script+execution+upload

Someone argued that this might be *wanted* by the application... (Some 
apps *wants* users to upload .php files which should then be 
executable...??!!).  I claim that it will be a serious minority of 
applications desire this, and the vast majority will want uploaded files 
to be non executable (regardless of extension)

Can we please, please, please try and make sure the recommended 
configuration includes examples of specifically *excluding* locations 
not expected to contain executable scripts...  My proposal above...

Ed W
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20100828/91df9e7a/attachment.html>