Avleen Vig Wrote:

-------------------------------------------------------

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.

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,88845,88942#msg-88942