nginx 0day exploit for nginx + fastcgi PHP

[Michael Shadle]

it's not a vulnerability with nginx, it's a widespread configuration
misstep teamed up with what I consider to be somewhat lazy application
code (it should check filetype and/or convert and normalize it to site
specifications and/or strip extra stuff inside of it ...)

there's a couple different ways to address it with nginx
configuration, and there is a way to address it in application code
too.

doesn't this fix basically say "if there is a period in the path
before the path ends with PHP throw a 403" - because then
/my.directory/foo.php would be denied, right?

location ~ \..*/.*\.php$ {
   return 403;
}


On Wed, Jan 26, 2011 at 8:07 PM, gdork <nginx-forum at nginx.us> wrote:
> 40 of my servers were compromised because of this issue and I just found
> out about it...aarrrghhhh.
> There are php cmd shell trojans everywhere now!
>
> I was able to easily replicate this issue, and the cgi.fix_pathinfo=0
> fix did NOT work on my systems.
>
> Adding:
>
> location ~ \..*/.*\.php$ {
> return 403;
> }
>
>
> Did solve the issue however.
>
> It is VERY common for image hosting sites to allow file uploads to the
> web directory.
> Any can upload a php file as an image and immediately execute it.
> nginx should NOT allow the fastcgi backend to execute code in a file
> that does not even exist.
>
> /blah/blah/virusimage.jpg/hello.php should never execute the hidden php
> code inside the file virusimage.jpg
> I wonder how many sites have been trojaned because of this.  Ive been
> searching vulnerability databases for days and never came across this
> nginx issue. :(
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?2,88845,169953#msg-169953
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://nginx.org/mailman/listinfo/nginx
>