Possible widespread PHP configuration issue - security risk

Ed W lists at wildgooses.com
Fri Aug 27 20:49:12 MSD 2010


  I'm not sure why a bunch of people are attacking me over this?

The problem is clearly worded.  I have taken some time to try and 
explain the issue. I have appealed for help designing a solution and yet 
half the responses are flames?

Look, I'm reasonably sure *my* servers are fine.  I don't really care if 
thousands of people I don't know get their servers taken over.  However, 
I have taken the time to try and help here and try to encourage 
discussion on a new and better baseline config - I don't see why I'm 
getting attacked over this?

Regards

Ed W


On 27/08/2010 16:22, Ed W wrote:
>  Look, not had a lot of success raising this quietly.  The Nginx wiki 
> has a number of very insecure PHP configuration suggestions.  Anyone 
> using these example configurations should immediately review their 
> configuration and ensure that they aren't vulnerable to an upload 
> attack where uploaded files might be accidentally treated as 
> executable files by nginx
>
> The core of the problem is that most of the example configurations 
> enable php scripts in *all* directories on the server.  Coupled with 
> relatively poor upload handling (in most PHP apps) and you have an 
> upload attack waiting to blow up on you.
>
> Try the following:
>
> 1) PHP Uploads allows (erk...)
>
> Create a file test.php containing:
> <?php echo 'hello' ?>
>
> Try and upload this.  If you can then probably turn off the server 
> until you fix the issue...
>
> The attack is to construct a URL which points to the uploads 
> directory, eg:
>     http://myserver/uploads/test.php
>
>
> 2) JPG uploads allowed, and wildcard ~ .php execution allowed
>
> Create a test file test.jpg as follows:
>     # echo -e "\xff\xd8\xff\xe0\n<?php echo 'hello'; ?>" > test.jpg
>     # file test.jpg
>     test.jpg: JPEG image data
>
> Now try and upload this test.jpg file to your server.  If it succeeds 
> then probably turn off the server until you fix the issue...
>
> The attack is to construct a URL which points to the uploads directory 
> and then append /.php on the URL, eg
>     http://myserver/uploads/test.jpg/.php
>
> Under *certain* configurations (wildcard php without a specific 
> SCRIPT_URL set) this will cause the execution of test.jpg by the php 
> interpreter
>
>
> The correct solution is where possible:
> - Enable PHP only on files in certain directories (if possible). 
> Exclude upload dirs!
> - Specifically disable (lots of) stuff on any upload locations!! 
> Remember configuration ordering in nginx puts regexp before named 
> locations (order is important)
> - Use try_files and other techniques to additionally lock down uri to 
> file mapping
> - Check for any Apache .htaccess files shipped with your app and 
> translate to nginx config where appropriate (eg blocking certain 
> locations completely)
>
> There are plenty of examples of dangerous configuration on the nginx 
> wiki.  eg the Wordpress initially presented configuration seems 
> vulnerable, but further down that page a more secure config is presented:
>     http://wiki.nginx.org/Wordpress
> The Media wiki example seems to show the same vulnerability:
>     http://wiki.nginx.org/NginxMediaWiki
>
> Please just treat your uploads directory carefully.  It's a huge 
> attack vector.
>
> Any volunteers to help improve the Wiki?  Anyone got some better 
> example configurations (which are secure)? I don't use most of the PHP 
> apps listed, so hard to test their configurations?
>
> Note this is not a problem with Nginx, this is a *configuration 
> issue*.  However, the docs recommend such an insecure default 
> configuration that there must surely be loads of people vulnerable 
> here...
>
> Cheers
>
> Ed W
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://nginx.org/mailman/listinfo/nginx




More information about the nginx mailing list