Not so highly critical?

The Drupal security team published a PSA to warn about upcoming security advisories. I shared my advice and predicted attacks within the hour after the security advisories are published. The security advisories are now published. Here is my followup.

I applaud the Drupal Security Team for warning about the highly critical updates. However the public service announcement (PSA) left the impression that this event was going to be much more serious than it was. Such a PSA would have been perfectly appropriate for SA-CORE-2014-005 "Drupalgeddon". But the only PSA there was in hindsight.

I guess it is resonable for the Drupal Security Team to be over cautious, especially given the lessons learned from Drupalgeddon fallout. And of course, such decisions and criticism is much easier with hindsight.

But now I am concerned how the Drupal Security Team can realistically raise the level further there is another vulnerability that is as serious as Drupalgeddon. Even if they raise the alert level using language in the PSA, will people still believe them? It reminds me of the boy who cried wolf.

Of course serious vulnerabilities like these are rare events in Drupal, so there is not yet a standard to compare alert levels to.

Comments

specific constructive criticism?

Hi Bevan,

Thanks for sharing your thoughts. You said that the PSA left the impression that it was going to be more serious than it was. Do you have any specific suggestions for how we could have given a more accurate impression of the severity of the event? Maybe you could post a "patch" to the PSA text to clarify what changes could have improved it?

When I wrote this post I

When I wrote this post I though a PSA at all for these SAs was too much. Now that I know about the Open Atrium factor I no longer hold that opinion.

The range of popularities of the modules was very useful data. I recommend giving that up front next time.

Regardless of the Open Atrium factor, the number of affected modules affected would have been very useful, and would not have compromised any sensitive information that I can think of. (Am I missing something?)

I assumed a Drupal API function was being readily misused and dozens of modules were going to have simultaneous security releases, not just three.

Mentioning the Open Atrium factor (in the SAs probably) might also have been useful. I am still wondering why there is such a discrepancy between the large number of OA downloads and the small number of registered installs on Drupal.org/usage. Has anyone worked that out yet?

They didn't cry wolf. This

They didn't cry wolf. This was a big issue. The coder module exploit doesn't require it to be enabled and it is included inside of various distributions like https://www.drupal.org/project/openatrium which has close to half a million downloads. Remote code execution is about as serious of an issue that you can get.

Wow. I didn't know

Oh wow! I didn't know about the Open Atrium factor there.

Coder does not have the level

Coder does not have the level of use that e.g. Views has, but it certainly is a popular module. The fact that this security issue is exploitable without the module being enabled is the critical factor here. I bet there are very few people that have some procedure in place that lets them use coder in development, but excludes the module entirely when deploying to production (which is good for thought).

The problem with the announcement is, that giving more information also means giving more information to malicious parties. Should they have said which module is affected up front? (NO!). Should they have said how popular the modules are? That's, arguably, still information that could lead to this turning into a zero day, which would be so much worse. And might pull people into a false sense of security; just because not everyone uses the module doesn't mean any particular company might not use a module on each and every site they deploy.

I think it was appropriate, but fully acknowledge the problem; it does feel like a bit of an anti-climax. I just don't know how that might have been prevented. Rest assured, for sites that did have this module installed, this was just as bad as drupalgeddon. I also think Drupalgeddon preparing us all is also a factor here; knowing what to do is boring. Boring is good, when it comes to this sort of thing.

Certainly it is a tricky one.

Certainly it is a tricky one. In my opinion this still pales in comparison to Drupalgeddon. Every Drupal 6 and 7 website was vulnerable. There were multiple widespread automated attacks for that within hours. Most public websites that were not patched within hours had backdoors installed.

This time, the number of affected websites is a fraction of all Drupal 6 and 7 websites. Were there any automated attacks for any of the vulnerabilities this time?

I should add that I do agree

I should add that I do agree that the number of affected modules would have been useful information.

Better Preperation for the PSA

My take is they could have said there was no issue with the core ahead of time, and only three modules were affected. I think that would have made the planning for dev shops much easier, knowing the work needed to be completed was less that what we expected. In fact, they could have given an estimate for the the total patching time for each affected module (without exposing the modules). That would not release any security info, but would give teams accurate amount of time needed to be secure.

- j

[Jim Curran – Partner – [email protected] – 212-691-1134 x111]

I agree the exact number of

I agree the exact number of modules would have been useful. I disagree the estimated patching time would have been useful. This varies by an order of magnitude depending on the tools used and (most of all) the experience of the person doing the updates.