In the following, I assume that we want to minimize the probability that
a user falls victim to an attack based on a preexisting vulnerability in
a piece of software, one that you, the security researcher, have just
discovered. I'll call this probability P.
D. J. Bernstein wrote:
It's not _my_ bug. It's also not my student's bug. It's the _program's_
bug. Sorry to have to break the news to you, but the attacker has had a
_year_ to exploit the bug if the program was released a year ago.
Only attackers who know about the bug, though. P is proportional to the
number of people, N, who know about the bug before it is fixed.
Observation 1: When you disclose the existence of the bug, you
increase N, which tends to increase P.
But P is also proportional to the time, T, that elapses before the bug
is fixed. By disclosing the existence of the bug, you greatly increase
the likelihood that the bug is fixed in the near term.
Observation 2: When you disclose the existence of the bug, you
decrease T, which tends to decrease P.
There is a trade-off.
Same delusion: you think that users are protected from security holes if
the security holes are patched before they're announced. Sorry, but
that's not nearly fast enough. Protecting the users means making the
programs secure before they're deployed in the first place.
But the question of vendor notification is one of software that *has*
been deployed with security bugs. In that case, notifying the vendor
before disclosure (with the understanding that public disclosure will
follow after a reasonable period of time) provides the benefits of
Observation 2, without the costs of Observation 1.
You would argue, I think, that by foregoing vendor notification, you put
the fear of God into programmers, and this will ultimately lead to the
eradication of bugs in the first place. I'm skeptical.
-David Eisner
