The Drupal Security Team has released a critical software update for the Drupal Content Management System (CMS).
Users with websites running either Drupal 6 or Drupal 7 are urged to upgrade immediately.
The advisory that explains what’s been fixed is tagged DRUPAL-SA-CORE-2015-002, and it flags one vulnerability in the “OpenID” module as Critical, with three other security holes labelled Less Critical.
→ For completeness, the official vulnerability designators are as follows: CVE-2015-3234 (critical); CVE-2015-3232, CVE-2015-3233 and CVE-2015-3231 (less critical).
Drupal 6 users need to go to version 6.36 and Drupal 7 users to version 7.38.
All earlier versions of Drupal 6 and 7 are vulnerable.
The “Login as Anyone” hole
The most serious issue outlined in the advisory is a vulnerability in Drupal’s OpenID module, a single-sign-on extension for the CMS that allows users to log in using OpenID:
A vulnerability was found in the OpenID module that allows a malicious user to log in as other users on the site, including administrators, and hijack their accounts.
This vulnerability is mitigated by the fact that the victim must have an account with an associated OpenID identity from a particular set of OpenID providers...
Attackers can exploit this bug to impersonate other users, including all-powerful administrators, and thereby gain control of an unpatched website.
Websites with the OpenID module enabled should see the option “Log in with OpenID” underneath the username and password fields on the login page.
Other problems
The three less critical bugs include two open redirect vulnerabilities that could allow crooks to send unsuspecting users off to booby-trapped sites, and a bug that could let users take unauthorised peeks at each others’ private information.
Drupal is the third most popular content manager in the world, powering just over 2% of all the world’s websites.
Even though 2-in-100 sounds like a small proportion, that nevertheless puts the number of Drupal installations in the tens of millions.
It’s a capable and mature system with a decent security record, but that sort of quantity makes it an attractive target for criminals.
Racing against time
When a serious vulnerability occurs it’s a race against time.
Administrators need to get systems patched before criminals can produce automated tools to find and attack vulnerable sites.
Automated attacks appeared within a matter of hours after a Highly Critical advisory was published in October 2014, leading the Drupal Security Team to make this extraordinary statement:
You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement.
If you were asleep during those seven critical hours, too bad!
That October 2014 update showed that passive alerts simply don’t cut it for software that’s so widely used and so exposed.
A compromised website isn’t just a problem for its owners, it’s a problem for all of us.
What matters isn’t the health of individual systems but the health of the ecosystem.
What to do?
What Drupal really needs is a mechanism to roll out critical security updates automatically.
Technically skilled users can roll their own updater using command line tools like Drush, but many people use Drupal because they can get by without a lot of technical knowledge.
An on-by-default solution modelled on the WordPress automatic updater would provide better protection for non-technical users, whilst giving power users the freedom to switch it off and do their own thing.
For now, though, you’ll have to update Drupal yourself.
gregharvey1978
> An on-by-default solution modelled on the WordPress automatic updater would provide better protection for non-technical users
On the contrary, as the head of hosting for a PHP hosting specialist that hosts both Drupal and WordPress sites, I gotta tell you the permissions required to make this work are an even bigger risk. Poor configuration to “fix” auto-updater issues with WordPress leads to writeable server directories exposed on the Internet and then GAME OVER.
I’ve seen it on more than one occasion, always with WordPress, always because someone set bad file perms, always in an attempt to make auto-updating work. WordPress auto-updating in and of itself isn’t insecure, but the inevitable happens when you make a feature like that – people who don’t know any better accidentally make their application insecure trying to get it working.
IMHO, people using Drupal should do so on a platform that can support automatic updates for them if they are not technically competent enough to do it themselves. Introducing an auto-updater would introduce the same potential for accidental back doors we see in WordPress day in, day out.
Mark Stockley
Thanks for the perspective from the real world. They do say that no plan survives first contact with the enemy…
Amanzi
Hi
How hard is it to do this security update, we are running drupal 6 and have been quoted 3 hours to this update. Would you say this is excessive.
Jeff
@Amanzi – D6 is not even in SLA anymore; therefore the patch for your site would have to be custom. I say that is not excessive at all considering all the precautions and testing that will need to be done. More importantly, you have a bigger issue on hard; and that is that you are still on D6. Please upgrade.