On 04/26/2015 04:04 AM, Mick wrote: > > Hmm ... I am probably affected by this change too. Running find for > '*.php.*' > et al, comes up with a tonne of files like this: > > /var/www/My_Website_Name/htdocs/modules/simpletest/tests/upgrade/drupal-7.filled.minimal.database.php.gz > > If I were to manually install protection, as suggested in the news item, > where > should I be doing this? In (umpteen) .htaccess files for each vhost, or > somewhere in /etc/apache2/* >
That's only a problem if those php.gz files can be uploaded by an untrusted user (and you want to stop them). That's a Drupal site, right? If you allow anonymous users to create accounts and upload files, then I could create an "mjo" account on your site and upload exploit.php.html to sites/default/files/mjo. Then I could visit, http://example.org/sites/default/files/mjo/exploit.php.html and it would run the script with the permissions of your web server. So, it could probably read the database password out of sites/default/settings.php. The half-assed way to prevent that is to block uploads of *.php files, but the point of the vulnerability is that not only PHP files will be executed. A better way is to disable the PHP engine entirely on any user upload directories. There was actually a Drupal CVE for that: https://www.drupal.org/SA-CORE-2013-003 And yeah, you should do that on every user-upload directory for every website you have. It sucks but you can use mod_macro if you have more than one e.g. Drupal site. I've got this in our Drupal macro: <Directory "/var/www/$domain/$host/public/sites/*/files"> # Deny access to user-uploaded PHP files. <Files "*.php"> Require all denied </Files> </Directory> But maybe it's safer to use, <Directory "/var/www/$domain/$host/public/sites/*/files"> <Files "*"> php_flag engine off </Files> </Directory>
