A Visit from the Drupal Security Police

Caveat: The following should be read with the understanding that I absolutely respect and admire the job that the volunteers of the Drupal Security Team do! Without their gallant efforts, Drupal wouldn't be the safe framework that it is. And as an aside, all module maintainers, developers, and anyone interested in learning more about how to lock down their site should read Cracking Drupal: A Drop in the Bucket, by Greg Knaddison (greggles), who happens to be a member of that crack force.

Last week, I received a visit from the Drupal Security Team, telling me that the Embedded Media Field module contains a XSS vulnerability.

That put the fear of Drupal into me! I know that some modules have even been removed from Drupal.org for having a vulnerability; I was not about to let that happen. The next day, I had a spanking new fix for it, and was ready to make a new release. That's when I actually read the instructions about what to do when you've been contacted by the Drupal Security Team...

How to avoid the panic

So the first mistake I made was to commit my fixes to CVS. I got all the way to making a new release on the project page. If you select Security update as the Release type, you get a new box that reads, Are you sure you want to mark this release as a Security update?

The rest states, If you select Security update, your release will not be published without the manual intervention of the Drupal Security Team. You should have already contacted the Security Team to coordinate a security advisory (SA) for your release before you committed any security-related patches.

Now I really started to panic. First I sent off an e-mail apologizing for not having read the notices more thoroughly, and what should I do next? Frantic to do something useful, I wrote a draft for a Security Alert. Then I went to bed and lost a lot of sleep.

The Security Alert you never got...

Fortunately, in the morning, Gerhard Killesreiter (killes) was quite helpful in IRC. He read my frantic e-mails and reviewed the issue. He pointed to the first line of the original issue, which read, Based on this PSA and security team policy regarding vulnerabilities only accessible via this administrator permission, this bug can be fixed through a public process. It even had a link to the original PSA regarding 'administer content types' permission. Derek Wright (dww) reiterated this in a later e-mail. Thus, my panic was for nothing, it was a normal bug rather than a security issue, which meant that it could have waited in line for its turn with the other issues in the queue, and I could have gotten a restful sleep.

Lessons learned:
1. If you've been contacted by the Drupal Security Team, don't panic!
2. Make sure it's an actual vulnerability, and not a simple bug.
3. If it's a vulnerability, fix it (you have up to two weeks), but don't commit any patches, and DON'T post anything publicly, such as to an issue queue, on your blog, or in a public IRC channel. If you need help, contact the Security team.
4. When you have a fix, still don't post it, but instead let the Team know. They'll review your patch and coordinate the rest with you.
5. Draft a Security Alert based on similar reports. That takes off some of the burden from the volunteer efforts.
6. In general, though I imagine exceptions are made, Security alerts are made on Wednesdays. The Drupal Security Team will let you know when to patch the file, commit the changes, and make a new release.

I hope my experiences help remind the next person who finds a vulnerability in their module to keep their cool. (By the way, I did both the graphics in this post; you're welcome to use them -- they're Creative Commons By-SA.)

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.