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.
