Possible widespread PHP configuration issue - security risk

[Raina Gustafson]

Hey Ed W,

Just want to say that while I'm not participating in this dialog since
it is over my head, I am listening and I do appreciate your asking
these questions, as well as your general commitment to Nginx and its
community.

Hopefully I am part of a silent majority in this regard.

Best,
Raina Gustafson

On Fri, Aug 27, 2010 at 11:49 AM, Ed W <lists at wildgooses.com> wrote:
>  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
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://nginx.org/mailman/listinfo/nginx
>