The press on vulnerabilities

Someone discovered a vulnerability in a Drupal module. He wrote up an advisory on it and the tech press got hold of it. There's no indication of how much PR went into getting the press to pay attention, so we'll hold off the "narcissistic vulnerability pimp" label for the moment. What the hell, let's examine the case for some good, old fashioned, unproductive name calling.

The advisory doesn't give a timestamp, but the Drupal bug report certainly looks like it was copied from the advisory text. It seems to be par for the course for our XSS specialist though. There's a whole list of advisories down the right margin of his site, and on every one I checked the dates for the blog post and the bug submission matched. So far so good. The writeups are awfully stilted, and posting under your own control rather than with the relevant project does come across as a publicity stunt. But so far, so good.

There is one thing that's new about this advisory though - it's got a CVE number. The Common Vulnerabilities and Exposures (CVE) project is funded by the US federal government (currently in the form of the National Cyber Security Division of the U.S. Department of Homeland Security) with the aim of ensuring common identifiers for vulnerabilities and exposures rather than having researchers and vendors issuing a confusing hodgepodge of names and numbers. The CVE number gives another clue or two (ain't timeline analysis wonderful?). A researcher applies for a CVE number, which he can then use in communications regarding the vulnerability. The CVE entry for this vulnerability lists the application date as the 27th of April, 13 days before the announcement and the submission of the bug to the development team.

One possible cause for the delay is hinted at in the vendor response section of the advisory. It boils down to the Drupal security team not believing that the problem requires a security advisory - in this particular case because the bug is in a release candidate module. It isn't the first time this has happened to him though, and previous bug reports would appear to have been made before trying to get a response from the Drupal security team.

All very puzzling, but this is drifting dangerously close to me just being an arsehole because I can't reconcile the alleged pimp's actions with my views on responsible disclosure. The real point of this post what happened after the report.

At some point after the advisory is published and the big report posted Dan Goodin from The Register gets hold of the story. He does some digging and posts this article on the matter later in the day. The Register are generally good about security reporting, one of the few voices not contributing to the FUD snowball effect. In this case it didn't work as well as normal though.

The article took an interesting angle on the problem, commenting on the recent White House release of code depending on the vulnerable module. That they did not find this vulnerability does raise some interesting questions about the thousands of eyes theory on open source software security. Where it all fell apart was in describing the range of systems rendered vulnerable, and that this probably didn't include whitehouse.gov. That the vulnerability could only be exploited by users who already had some level of admin privileges was mentioned, and a Drupal security team developer was quoted as saying that the situation which could be exploited was very rare (in his private capacity of course).

A little bit more detail on the "very uncommon" would have gone a long way to clarifying the situation. I'm certainly not trying to pick on greggles here, he does fabulous work on securing Drupal. I'm not even so sure that Dan did anything wrong here. Something just fell through the cracks. That something comes in three parts:

• What is the default state of the privileges required to exploit this vulnerability? Vulnerabilities in things that are turned on by default are a lot more serious. It's common to point out when default configurations are affected, and it should be pointed out when they aren't. In this specific case the permission required is only available to the site super-admin by default, quite an important limitation on the vulnerable population I would think. The vulnerability is also specific to allowing users who can manage blocks to escalate their privileges, it doesn't create any new opportunities for abuse by the super admin.
  
• Under what conditions would these defaults have been changed? Obviously only relevant if the default state isn't vulnerable. Blocks are core to a site's layout and information architecture, so core that they may well be set up once and really not regarded as manageable content. Delegating the authority to manage them is therefore highly unlikely.
  
• Is there a specific installation in question here/How does this affect the specific installation in question here? This will often be impossible to answer definitively. The White House site does look like the blocks are quite fixed though. So it looks like the block admin privilege would not need to have been delegated.
  

Software companies have PR departments to deal with this sort of thing. Most OSS projects don't. So developers or implementers end up fielding the questions. These tend to be people of technical bent, opposed to spin even if they were able to do it. Answering these questions, even if they aren't asked, doesn't come close to being spin but it will help to keep the reporting reasonable. It would be nice if they were being asked in the first place though ...