Possible widespread PHP configuration issue - security risk

[Cliff Wells]

On Fri, 2010-08-27 at 18:48 +0100, Ed W wrote:
> On 27/08/2010 18:05, Cliff Wells wrote:
> > Nevertheless, I've updated the MediaWiki entry.
> 
> I'm still having problems getting to the wiki - no .js files are loading 
> which is causing some wierd stuff to happen.

I do not see any issues... does anyone else have a problem?

> However, my opinion is that just adding try_files is only a partial 
> fix.  If some way is found to upload .php files (bad wikipedia config) 

I don't think we should try to overcome people's intentional
configuration.   Not only is it completely their fault if they go
through the difficulty of enabling a feature that is off by default, but
now we are attempting to impose our will on a user who has made a
specific decision.  This is always a bad road in software. 

> or some other exploit is found that can bypass the try_files then we 
> still have an issue.

Not going to worry about such speculative future issues.  If such an
issue arises it will need to be addressed as an Nginx patch, not a
configuration option.

> 
> My mediawiki config does this:
> 
>                  location ~ .*.php$ {
>                          include /etc/nginx/fastcgi_params;
>                          if ( $uri !~ "^/images/") {
>                                  fastcgi_pass    localhost:9000;
>                          }
>                  }
> 
> Others have already pointed out that we can do better than my IF.  
> However, your try_files, plus the explicit exclusion of the /images/ dir 
> go a long way to secure mediawiki.  Also I think the specific exclusion 
> of the /images/ dir becomes quite self-documenting, whereas the 
> try_files is quite a subtle fix?

It is subtle, but all fixes are, because the underlying vulnerability is
quite subtle.  What user isn't going to look at that and say to
themselves "why do I need this if statement?".   Just use the try_files
and add a comment to its purpose.

Cliff