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
Full disclosure is the policy to immediately disclose the details of a
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
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
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
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.
to post comments)