Avleen Vig Wrote:
-------------------------------------------------------
> This is currently doing the rounds, so I thought
> it pertinent to post
> it here too.
>
> http://www.webhostingtalk.com/showthread.php?p=680
> 7475#post6807475
>
> I don't know what nginx should do to fix this, but
> there are two
> workarounds given.
> If you allow file uploads (especially things like
> images) and use PHP
> FastCGI in the back end, you should take a loot at
> this now.
> The exploit allows for any arbitrary file which is
> uploaded, to be
> executed as PHP.
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://nginx.org/mailman/listinfo/nginx
I can confirm this exploit worked with my site using nginx 0.8.36 and php-fpm 5.3.2 svn. This is on my password protected ssl admin subdomain where I use:
location ~ \.php$ {
include /etc/nginx/fastcgi_params;
fastcgi_index index.php;
fastcgi_param HTTPS on;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass php;
}
I copied my phpinfo.php to be badfile.jpg and also badfile. Then I could access either:
https://admin.mysite.com/badfile/foo.php or
https://admin.mysite.com/badfile.jpg/bar.php
and it would run it. On my drupal sites I'm more careful and use:
location = /index.php {
...
fastcgi_param SCRIPT_FILENAME /var/www/$host/drupal/index.php;
...
}
only (there's actually 5 php files in drupal, but only index.php is a must), so the vulnerability doesn't work. But some things (e.g. wordpress) use tons of php files so it'd be a pain.
I tried changing to:
cgi.fix_pathinfo=0
in my php.ini file and that solved the problem. This also seemed to work fine:
location ~ \.php$ {
try_files $uri =404;
include /etc/nginx/fastcgi_params;
fastcgi_index index.php;
fastcgi_param HTTPS on;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass php;
}
since it checks for the existence of the file at that path. Even if I put in an actual existing file like:
https://admin.example.com/test.jpg/apc.php
I still get a 404. So folks should try adding:
try_files $uri =404;
to their php blocks and see if that solves the problem for them as well.