Security risk of automatic Drupal updates

Yesterday I had my fears confirmed about the Drupal Automatic Updates initiative. It requires sites to be able to modify core Drupal files. While this makes it easier to fix vulnerabilities, it is not something you want when your site is actually being attacked. The best way to protect against someone exploiting a vulnerability to modify your Drupal core files is to change the file permissions so that your site cannot modify them.

The Automatic Updates team has done amazing work to make the update process itself trustworthy. The problem is that if you allow your site to modify core files, you cannot guarantee that only trustworthy processes will use it. I’ve seen a site that had malicious code added to almost all its files and had malicious files created in all its folders. I’ve been on an IRC chat with a Drupal site administrator who was trying to clean up a site that was being attacked so persistently that as soon as it came back up it would be compromised again.

There is a workaround. Instead of giving the site permission to modify core files, you can give that permission to a different user and run a command line script as that user. But you can already create scripts to update your site automatically. If you want to use the admin UI, it will not work.

What makes this frustrating is that a solution already exists. Starting in Drupal 7, Drupal has supported SSH file transfer. The Update module uses it to update contributed modules. If Drupal does not have permission to change a contributed module, the Update module checks for the SSH2 PHP extension. If it exists, it prompts for the user name and password of the user who has permission to change contributed modules. No credentials are stored in Drupal, so only an authorized use can modify files. It seems that this feature is so obscure and rarely used that the Automatic Updates team overlooked it.

I hope to get support for SSH file transfer added to the Automatic Updates initiative before it is finalized.