A question came across the Drupal Developer's list today asking whether Drupal could auto-update itself, like WordPress. As someone who thinks about security a lot, the very thought of this horrifies me.
It's a bad idea for several reasons, but the biggest reason:
It could easily lead to the biggest most powerful bot-net on the planet.
This could just as easily happen to WordPress, too. It already has, in fact, to a small extent.
See, here's the thing. Criminals are lazy. They want to get the biggest possible payoff for the smallest amount of work. Having a single site that can be compromised, and lead to taking control of millions of web sites -- well, that's an awfully big payoff for a pretty easy attack.
And here is one Achilles Heel of open source -- the crown jewels are out there in the public, with minimal security.
Think of Wikipedia. On the whole, it has become the largest, best source of human knowledge out there. But if somebody wants to trick you into believing something, all they have to do is modify a single page, and get you to read it (and believe it) before somebody changes it back.
Attacking the repository for an open source project is a bit more protected -- access is only given to trusted individuals to make these kinds of changes, at least for core parts of the program. But that just means it's up to the security practices of those individuals -- if an attacker can get the credentials of one of those users, they can get malicious code into a repository. It has happened to several large open source projects in addition to Word Press -- Debian, the Free Software Foundation, and yesterday, Kernel.org that houses the main Linux kernel.
All of these attacks are generally detected relatively quickly. There are lots of ways of identifying malicious code that makes it into software repositories. However, there is some delay between the repository getting hacked and the malicious code getting identified -- a window of time where people updating their software may download the nasty stuff.
The problem with web projects like Drupal and Word Press is that a huge number of people run these in production environments, live on the web. If a high number of these all get updated, how many site administrators would notice? How long would it take to get millions of hijacked web sites fixed up? If a site administrator is not savvy enough to apply updates manually because all they want to do is push a button to auto-update, why is it a good idea to expect them to clean up after their site has been hacked?
This is wrong on so many levels.
So. Recognizing that site updates can be critically important to close vulnerabilities that might also lead to your site getting hacked, how do you apply updates safely? Here's our checklist:
- Evaluate each update to assess its priority. Does it fix something that left unfixed could lead to your site getting broken into today? Is this likely to happen? If so, drop everything to evaluate and rush out the fix. If not, schedule the remaining items into your normal work flow.
- Wait a few days to see if others experience problems upgrading, and review new issues on the project's issue queue.
- Evaluate the contents of an update to see if the code changes match what's in the change log.
- Back up the site and database entirely, in case something goes wrong.
- Apply to a test version of the site, and see if we can find anything that breaks.
- Commit the new code to source control, so we have the capability of rolling it back.
- Ask client to review the updates on the test site, if the client is heavily involved with site administration.
- Roll out the update to production, notify the client that it's up.
- Verify that the updated code operates correctly.
While you might be able to script a backup job to run before an automatic upgrade, and while you also might be able to kick off some automated tests (if you have any -- for Drupal they were added in version 7), the rest of the above checklist would get totally bypassed by automatic updates.
Most of the time, skipping those checks might make parts of your site break. Even doing those checks might break some of your site, but the code management can make tracking down the source of the problem much easier. Making it easy to apply updates is a good thing -- but it's not a replacement for keeping track of what's going on with the software you're using. Remember that if your site gets hacked, it's usually your visitors (customers?) who suffer -- currently the most common thing done with hacked sites is making them hosts for spreading viruses and malware to Windows machines. Do you really want to put your customers through that?
Have a different view? Please share in our comments below!
John, I am going to disagree with you on this one, for the following reasons:
1. You can evaluate each Wordpress update before you apply it. Wordpress' auto update doesn't run by itself. You still need to click the update button manually, in order to update Wordpress.
2. You don't need to update Wordpress as soon as the update it available, but can wait a few days / weeks to see if the update caused problems for other users.
3. Evaluate the contents of an update to see if the code changes match what's in the change log.
4. You should backup any CMS and database before doing any update, regardless if you do the upgrade manually or automatically.
5. If a backup was made, and the upgrade broke your website, you could restore the backup in order to "roll back" your website to the previous version.
6. How many webmasters really commit the update to source control? IF they don't do it with a manual update like Drupal, why would they do it with say Wordpress?
7. Updates could be done on a test site, for the client to evaluate before doing it on the live site, both on Drupal and Wordpress
8. Roll out the update to production, notify the client that it's up. - also both with Wordpress & Drupal
9. Verify that the updated code operates correctly. - also both with Wordpress & Drupal
Wordpress' "auto update" merely downloads the update directly from the server and "installs" it directly onto the website, instead of you downloading a tar.gz file and uploading it via FTP. Most *lazy* web masters don't follow half of your suggested steps when they apply updates to any script, let alone Drupal.
Hackers could as easily infect the Drupal / Joomla / {name-your-CMS} repositories as they could with Wordpress and as many people's websites could have the infected code if they just download, unzip and upload the updates to their websites.