Drupal Security: Forewarned is Forearmed

Thu, 22/03/2018 - 09:54 -- James Oakley

Yesterday, at 7.13pm, the Drupal Security Team issued a public service announcement: Drupal 7 and 8 core highly critical release on March 28th, 2018 PSA-2018-001.

This needs a bit of background to understand.

How Drupal Core Updates Normally Work

Updates to Drupal Core fall into one of new kinds.

The first kind squashes bugs or introduces minor new functionality. There is a set window each month when these are released, to help site developers to plan. It's normal practice for there to be an announcement about a week beforehand as to whether there will, or will not, be such a new release. The more notice you've got, the more you can plan when you want to apply the update.

The second kind addresses security vulnerabilities in the Drupal code. There is also a set window each month when these are released (unless a vulnerability is being actively exploited in the wild, and speed is of the essence).

These are carefully managed. The person who discovered the vulnerability works with core maintainers and the security team to fix the problem. Nothing is announced by any of them until the problem is fixed. The last thing you want to do is tell would-be hackers the details of a vulnerability they could exploit, while you work on a fix. This is standard within the software industry.

The moment the update is released, there is a problem: Drupal is open-source, and security releases tend only to fix the vulnerabilities being fixed at that time. Any other bug fixes can wait for the next general update. So any hacker can easily diff the new version against its predecessors, and find what was patched fairly quickly. Closed source software will wait a week or two after releasing a fix before announcing what the vulnerability was; Drupal gains nothing by doing so, so the security release is usually accompanied by an announcement as to what was fixed.

So when do the Security Team announce that there's going to be a release (without giving out any details)? It's a balancing act. By giving notice in advance, site maintainers can be prepared for the update. But hackers are also put on notice, and they could start combing the codebase to find the vulnerability. So, in the normal run of things, the chosen balance is to announce the monthly window when a security update could occur, but not to say in advance whether one will occur. (On occasion, if the update window falls across a major holiday, the Security Team have been known to reveal that there won't be a security release, so that people aren't left on standby needlessly).

What happened yesterday is therefore unusual. The Security Team decided it was worth the risk that they'd be forewarning the hackers, so that site maintainers could be prepared to update quickly. That means it's the kind of vulnerability where every minute counts. It must be a far more serious issue than usual.

We've been here once (and a half times) before

The most notable time we've been given advanced warning of a core security update was SA-CORE-2014-005, which acquired the nickname "Drupalgeddon". That hit both technology and mainstream news outlets, and was still being actively exploited 18 months later. It was so serious that the security advisory was followed up with a public service advisory that said

"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."

7 hours.

The vulnerability was given the highest possible risk score of 25/25. That means it is trivial to exploit this, with no need to have a user account on the site in question, revealing any private data from the site, corrupting the site's integrity at any level, and a known exploit already exists. Ouch!

Furthermore, the advice given in that same PSA was that there was no way to clean up a hacked site. If you hadn't updated or patched within that 7 hour window, you needed to restore your site to a backup before the announcement.

If you're interested to read more about how that vulnerability worked, and how it could be exploited, Matt Korostoff has written it up in a very easy to follow way.

I say this has happened one and a half times before. On 17th April 2017, PSA-2017-001 announced that there would be a security release for Drupal 8.3.x and 8.2.x two days later, 19th April. The team made it clear, however, that this one was much lower risk than "Drupalgeddon":

This vulnerability does not affect all Drupal 8 sites; it only affects sites with certain configurations. It requires authenticated user access to exploit. The security release announcement on April 19th 2017 will make it clear which configurations are affected.

So we had SA-CORE-2017-002, with a risk score of 17/25.

That's the half a time it happened before. Other than that, I can only think of the one (Drupalgeddon). If the vulnerability to be fixed on 28th March is as serious as that, all Drupal site maintainers need to be ready to patch as fast as possible. Every hour could count

Next Week

So back to next week, and PSA-2018-001. Aside from the fact that a full week's warning is unprecedented (nearly unprecedented, but the precedent we have is not reassuring), there are other clues that this could be major:

The Drupal Security Team urges you to reserve time for core updates at that time because exploits might be developed within hours or days. Security release announcements will appear on the Drupal.org security advisory page.

While Drupal 8.3.x and 8.4.x are no longer supported and we don't normally provide security releases for unsupported minor releases, given the potential severity of this issue, we are providing 8.3.x and 8.4.x releases that include the fix for sites which have not yet had a chance to update to 8.5.0.

There's no hint at anything mitigating this, like certain access levels being needed in order to exploit the vulnerability.

Journalists interested in covering the story are encouraged to email security-press@drupal.org to be sure they will get a copy of the journalist-focused release. The Security Team will release a journalist-focused summary email at the same time as the new code release and advisory.

So this could be of interest to the media.

Thank you to the Security Team

Let me close by thanking the Drupal Security Team. Drupal has a reputation as one of the most secure, if not the most secure, CMS / web development platform out there. That is because security issues are not ignored, and are not managed clumsily.

With any platform the size of Drupal, it's not a matter of whether but when someone finds a vulnerability in the code tree.

This is a case study of how well Drupal reacts when a security issue is reported or discovered. That is what makes Drupal so excellent from a security standpoint.

So, to all members of the Security Team: Thank you for your hard work.

And to the rest of us, mere site maintainers: Let's take their communication on board, and be prepared.

Forewarned is forearmed!

Blog Category: 


David Cameron's picture
Submitted by David Cameron on

If the vulnerability to be fixed on 28th Feb is as serious as that...

28 Mar?

James Oakley's picture
Submitted by James Oakley on

Thanks - fixed that for you. (And it's good to know that someone is reading carefully!)

James Oakley's picture
Submitted by James Oakley on

OK, so the fix is out: SA-CORE-2018-002.

This was a 21/25 security risk level, so not quite the 25/25 that SA-CORE-2014-005 had. It dropped 3 points from the maximum: 2 because the exploit was only theoretical and not yet known in the wild, and 1 because a configuration change could mitigate the vulnerability.

The astute amongst you will wonder where the 4th risk level point went. (21/25, add 3, makes only 24/25). Well, I've added up the risk level scores, and I think the maximum achievable is 24. Oh well.

I'm pleased to say that this site is fully updated, as are the others I run. Thanks to the Security Team's warning, that was done 12 minutes after the announcement. Once again: Kudos to them!

If you've not yet updated your Drupal site, please do so immediately.

Balazs Janos Tatar 's picture
Submitted by Balazs Janos Tatar on

Thanks for the heads-up @James,

I've updated the risk level definitions page and changed it to 0-24 as it's right.



James Oakley's picture
Submitted by James Oakley on

I knew there had to be a problem, because the maximum totals in the handbook page add up to 24, so if the risk calculator gives a maximum of 25 then one of the individual scores must be different from those listed in the handbook. Sure enough:

The risk calculator is assigning 4 points to "E:Exploit = Exploit exists (documented or deployed exploit code already in the wild)"

The handbook page states: "E:Exploit = Exploit exists (documented or deployed exploit code already in the wild) +3 points"

Add new comment

Additional Terms