On 8/27/10 11:22 AM, 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...

It doesn't work on the apps I mentioned. It simply won't upload.

But again, it is still up to individual webmasters to test and secure
their own apps.

>
> 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

So stop complaining about the Wiki and fix it. The Wiki is after all a
community project. If you have better ideas post them.


>
> 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
>


--
Jim Ohlstein

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx