Security

Vulnerability disclosure policies

Security vulnerability disclosure policy is contentious. Vendors typically argue for "responsible disclosure", while some in the security community think that "full disclosure" is the only way to fully protect the users of vulnerable software. There are other disclosure policies as well, but it is important to note that security researchers are under no obligation to disclose flaws that they find at all, which is something that all entities distributing software—vendors, projects, distributions, and so forth—should keep in mind. Anyone who finds a vulnerability and points it out is doing so as a favor, regardless of how the disclosure is done.

Full disclosure is the policy to immediately disclose the details of a vulnerability as soon as it is found. That may alert attackers to the flaw, but it also alerts users and allows them to make choices about mitigating the problem. It also puts enormous pressure on the maker of the software to produce a fix in a timely fashion.

Responsible disclosure, on the other hand, puts the choices largely in the hands of the vendor or project. The idea is to give the software maker some amount of time (usually on the order of weeks) to fix the problem and release a patch before any disclosure of the flaw is made. It is meant to be "responsible" to users, so that attackers don't get a leg up on the installed, vulnerable software before there is a fix available. But, responsible disclosure pre-supposes that attackers are not already aware of—and exploiting—the flaw.

There has also been a trend toward "partial disclosure" in the last few years. Typically practiced by those looking to make a name for themselves—and/or bring publicity to their research firm—partial disclosures are pretty much what they sound like: the announcement of the existence of a flaw with as few details as possible. But there is a fine, and difficult to draw, line between providing enough details to convince the security community that there is a flaw and not disclosing so much that others can figure out what that flaw is. Eventually, partial disclosures become some other kind of disclosure, either through the efforts of the original finder, or because other researchers were able to figure out the flaw from the clues.

Something of a new wrinkle in disclosure policy is zero (or no) disclosure—at least without payment. VUPEN Security has announced two vulnerabilities in Microsoft Office 2010 on its security blog, but is unwilling to disclose them to Microsoft until and unless the software giant ponies up for the information. The H quotes VUPEN CEO Chaouki Bekrar: "Why should security services providers give away for free information aimed at making paid-for software more secure?"

While there is nothing that requires security researchers to alert software makers to bugs in their code, it is a longstanding tradition to disclose those flaws. But security companies may now be more focused on mitigating any vulnerabilities they find for their customers, leaving the rest of the user community high and dry. At least until some deep-pocketed organization steps up and pays. While some in our community might be amused that Microsoft (and its users) are being treated this way, it may not be so funny if it starts happening to Linux or free software projects.

Microsoft is hardly blameless here. For years it treated security vulnerabilities as a public relations problem at worst. It has also had a rocky relationship with the security community, which has led to more than one exasperated disclosure of a "zero day" vulnerability. A recent privilege escalation in Vista and Server 2008 is just such a disclosure; researchers annoyed by criticism of Tavis Ormandy for the release of a Windows vulnerability formed the "Microsoft-Spurned Researcher Collective"—MSRC, just like the Microsoft Security Response Center—to anonymously make these kinds of zero day disclosures. It should be noted, though, that Microsoft is not alone; the Linux kernel community has also had a combative relationship with security researchers at times.

While there is little direct harm in security researchers keeping their knowledge of specific vulnerabilities to themselves, there is certainly the potential for harm with partial disclosures. This relatively new zero disclosure policy is, in reality, just a form of partial disclosure, and may provide attackers with just enough information to focus their efforts. If these researchers truly want to be paid for their efforts, they would be much better served by working with the established players in the vulnerability buying business (Tipping Point and others) or by approaching the affected vendor privately. For vulnerabilities in Linux and other free software, though, it's not particularly clear who would be willing to pick up the tab. We will just have to hope that, if that happens, any loud zero disclosure of a flaw like that provides enough clues for the "white hats" to track down the problem in short order.

Comments (14 posted)

Brief items

Quotes of the week

Comments (1 posted)

New vulnerabilities

acroread: multiple arbitrary code execution vulnerabilities

Comments (none posted)

avahi: denial of service

Comments (none posted)

bugzilla: information disclosure

Comments (none posted)

gcc: directory traversal

Comments (none posted)

libtiff: out-of-bounds writes

Comments (none posted)

mahara: multiple vulnerabilities

Comments (none posted)

mediawiki: multiple vulnerabilities

Comments (none posted)

mediawiki: multiple vulnerabilities

Comments (none posted)

rpm: privilege escalation

Comments (none posted)

Page editor: Jake Edge
Next page: Kernel development>>