On 27/08/2010 03:20, Jim Ohlstein wrote:
> On 8/26/10 7:07 AM, Ed W wrote:
>
>
>> No one seems quite as excited about this as I feel? What am I missing?
>
> What you say is true, that such a file would be parsed as PHP if
> requested in that manner but it needs to be uploaded successfully
> first. Most modern PHP based galleries will not upload a file ending
> with ".jpg" unless it actually is a JPEG. Same with a file
> misidentified as a PNG. Try it with a phpinfo script. It won't upload
> into apps like vBulletin or IPB. I can't speak for a lot of others
> since I haven't tested them.
>
> If an app does upload a misidentified file so easily, then the onus is
> on the webmaster to configure nginx correctly or, more simply, to not
> use the app or to not allow uploads from untrusted sources. The method
> proposed by Mike will work fine for such insecure apps, but the real
> fix is to fix the app.
>
> The "try_files" approach will be much more efficient than any "if"
> will be if you insist on using an insecure app.
>

I still think you guys aren't getting the point?

The wiki *documents* an insecure method of setting up many PHP
applications. It's almost the number one security vulnerability that
you MUST secure your uploads directory and assuming that the PHP
application can/will do this perfectly is optimistic at best. A little
help from the webserver is your minimum second layer of defence really.
In fact many "secure" PHP applications delegate security of the upload
directory completely to the webserver and ship with .htaccess files to
disable php access...

It's not about whether you and I can setup a secure nginx setup, it's
about the wiki encourage perhaps tens of thousands of users to setup
their systems so that they can be *trivially* broken into. Of course we
can all sit back and call the users who followed "our" instructions
idiots when this turns into a mass epidemic, but in the meantime there
is a huge encouragement to setup a bunch of PHP apps so that they can be
trivially broken into?

You are correct that all kinds of vague ways can defend against various
aspects of this. However, bottom line is that there are few perfect php
applications which perfectly filter uploads. There are a lot of clever
ways to sneak junk past upload filters

Just to knock one final myth on the head. Construct a .jpg file like
this and it appears to me that it will work fine and also slip past many
file filters:

# echo -e "\xff\xd8\xff\xe0" > test.jpg
# file test.jpg
test.jpg: JPEG image data
# php test.jpg
????
hello


The *correct* solution is to:
- Enable PHP for the minimum number of file locations possible
- Treat the upload directory as a special case and disable as much as
possible there (beware ordering in conf files)
- If possible use try_files on certain locations to further limit scope
of attack (may not be possible everywhere)

Why doesn't anyone think this is a huge accident waiting to blowup?

Ed W


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