Posted by perusio on November 21, 2013 at 10:09am
There's the Drupal core security advisory just released that talks about the uncontrolled PHP execution. here's some remarks.
-
If you're using the config available on the Nginx wiki you're vulnerable.
That config has a catch all location
location ~ \.php$ {...}for handling
PHP script execution. -
If you're using any of the configs recommended on the [Nginx group] (https://groups.drupal.org/nginx) you're safe.
-
The issue has been reported at the pitfalls page of the Wiki for a long time. So it's not exactly breaking news.
Discuss here if you have any issues/questions so that we can help you lockdown your server config regarding PHP executions.
Thanks,
Antonio
Comments
Thanks so much for posting
Thanks so much for posting this!
As we worked on the issue we discussed exactly this point but didn't feel we had a good place to point to regarding nginx. It probably would have been smart to add you to that security issue earlier in the process so you could help draft some nginx advice (especially seeing that you did it anyway).
knaddison blog | Morris Animal Foundation
Someone was asking in the
Someone was asking in the #drupal IRC channel about this yesterday, and I told them that if they were using the Perusio config (they were), they were probably okay since it's so strict about the PHP scripts it will allow execution on. Good to know I wasn't just talking out of my rear end.
The Boise Drupal Guy!
Recommendation for locking down IIS on Windows?
I found this post from April 2012 for a web.config file that would disable PHP execution.
https://groups.drupal.org/node/226059#comment-740629
Is this still the recommended way to prevent PHP execution for Drupal on Windows with IIS?
The best answer is to try it
The best answer is to try it out and see if it works. After all, that's what led to discovering this problem.
knaddison blog | Morris Animal Foundation
Tested and it works
Limited testing shows that the web.config from the April 2012 post works and prevents PHP from being executed.
Edit
Further testing shows that image styles are not generated if the public files directory has a web.config file. Original images are uploaded however the various sizes, e.g. thumbnails, are not created. Even a very simple web.config file with no restrictions causes this.
Furthermore, Nginx based
Furthermore, Nginx based Aegir installed by Barracuda and Octopus already has even more strict configuration than before, namely, /index.php is no longer available directly (it is internal location now, like in the perusio's config), so we aggressively force clean URLs with built-in redirects to .php-free URI, /update.php is not even accessible for not logged in admin user, and everything (.php) else is denied by default (as always has been), with only a few exceptions for known contrib modules with explicitly allowed paths. This means that any BOA system installed in the last 4 years is not vulnerable / affected by recently discovered vulnerabilities in Drupal and Nginx.