Software bugs

Dave Goldsmith has some experience trying to report a security vulnerability to a company that does not have a security-specific process:

I reply:

Can you give me some guidance on your response guidelines to security vulnerabilities? Is there a timeframe that you try and have vulnerabilities fixed by?

They reply:

Hi David,

We’re always looking for new ideas and fixes to roll out in future updates but as as rule we don’t comment on possibilities or timeframes.

His commenters discuss the lack of reporting guidelines for security flaws in websites. In a more recent post, he reveals that 37signals was the previously unnamed vendor, and writes:

Vulnerability reporting should not be handled in the same way that you manage feature requests.

[Via ZDNet, which discusses whether treating security flaws as defects is a more effective way to communicate the problems they cause.]

Issues to consider here are the usual with security bugs: vendor communication versus disclosure. In the case of security problems in end-user software the problem with disclosure is the race for users to patch their systems against attacks being launched on those systems, with consequences that vary per attacked system. When it’s a website with a security problem, disclosure has a different weight, as rather than leaving some users in the lurch while a fix is rushed out (or leaving them to fight for one), the vulnerability can largely be fully exploited immediately. There’s only one target. You may be writing off this vulnerability’s consequences all together in the hope of future responsiveness from the vendor.

Popularity: 64% [?]

The bMighty Blog describes how a bug in Firefox which was present in the 2.x series and was in the 3.0 released version has created some controversy: did the security researcher know about the bug earlier and choose the timing of the announcement purely for the publicity?

In other words, this is an issue that could have surfaced at any point in the past two or three years — but did not. Instead, news of the bug surfaced just five hours into biggest, and perhaps most important, software launch in Mozilla’s history.

The article goes on to describe various possible motivations for timing a security announcement with a highly publicised major release: it might benefit the researcher, but it also hurts Mozilla a lot. This is hostile bug reporting at its finest, if it wasn’t a coincidence.

Popularity: 51% [?]

Havoc Pennington describes the coordinated release process for security bugs:

The simplest thing is to quietly notify any of the major Linux or BSD distributions and let them take it from there… Once you notify someone, wait to hear back. The upstream maintainer would normally announce the vulnerability and commit patches to CVS at the same coordinated time that vendors post packages. If you patch in CVS before anyone is ready with packages, your users are vulnerable during the gap (and generally unhappy about it). Worse, by committing a patch to CVS you’re doing something that a black hat could notice, but most sysadmins will not notice.

Popularity: 100% [?]

Reporting a program’s vulnerability to an attack of some kind is a bit different to reporting normal bugs, because public exposure of the vulnerability may cause it to be exploited before the developers can develop a fix. Hence, normal bug reporting procedures, such as making an entry in a project’s public bug database, may not be the best approach. In this case, you may want to approach the vendors or developers privately, even if it goes against their bug reporting guidelines.

CERT’s policy (via SLUG) gives vendors at least 45 days to address a security issue before advising the public. Their Vulnerabilities, Incidents, & Fixes FAQ gives some guidelines for people who have discovered vulnerabilities.

The Organisation for Internet Safety has also issued a document called "Guidelines for Security Vulnerability Reporting and Response Process – V1.0" [780kb PDF file].

Popularity: 58% [?]