Slow reply - apologies

>> See, just checked the wiki. Surely this example allows you to
>> immediately upload a new file with a .php suffix and exploit the server?
>> http://wiki.nginx.org/NginxMediaWiki
> Mediawiki doesn't allow that. It filters by an allowed list of
> extensions, and .php isn't among them.

Uh uh. As demonstrated above, you appear to be able to bypass this by
adding /.php to the URL

Lets spell this out. Anyone using these suggested default
configurations is massively vulnerable to injected php scripts. Just
upload an "phpinfo()" script named hello.jpg then browse to
http://url/hello.jpg/.php and watch as your php gets executed

There may be a bunch of ways that this isn't a vulnerability on all
configurations, but the point is this is a *default* and a simple scan
of a bunch of nginx machines is going to reveal a high count of machines
vulnerable to injection? Not sure why this isn't getting more attention?

Look I'm being a bit subtle about this, but I would have thought this
was an urgent scramble to fix kind of thing?

> Of course, if you can also let Nginx provide another ounce of
> prevention, then all the better.

This isn't an nginx "problem", it's a configuration problem. "we" (the
wiki) are advising people to incorrectly configure their PHP apps

> Unfortunately most PHP applications
> expect to be able to run arbitrary PHP scripts from almost any directory
> under the sun,

Hmm, I disagree on "most". The small selection that I use tend to use
only a small number of locations.

In my config I either:
- Move the data dirs out of the htdocs patch altogether (gallery2 and
others support this)
- Configure only certain files or restricted directories to be treated
as PHP apps
- Reluctantly I might do the reverse and allow all .php files to be
treated as PHP, but then add an "if" in the location to prevent the data
dirs from being scanned. I needed to do this for mediawiki for
example. Note that this is a tricky config because generally you use a
regexp location for the .php and so you can't override it with a
"location /uploads" since it's parsed later - instead you need to add an
"If" into the php location...

> or simply
> make sure that it's not possible to upload files ending with .php.

This is a partial solution at best. As shown previously it doesn't
actually help you for a lot of configuration examples since trivially
appending /.php on the end allows you to get the file to be parsed by
the PHP interpretor under many configurations?



Webapps are often built assuming apache and will ship with a bunch of
..htaccess files that stop the php interpretor running files in that
location, ie the upload files dir will have a .htaccess in it turning
off the php interpretor. Now even under Apache this is hit and miss
because many installations will disable htaccess files for performance
reasons (or not allow all actions from the .htaccess). Of course when
you install your PHP app on nginx I would guess it's quite normal for
the operator to forget to scan for .htaccess files and translate these
to nginx config rules (not nginx's fault, this is an app configuration
issue)

No one seems quite as excited about this as I feel? What am I missing?

Ed W

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