Re: ssl security desaster
Klaus Ethgen <Klaus@Ethgen.de> writes:
> Ehem, is it your idea of security to make it secret (like Microsoft do
> often)? It is never ever a good idea to make security issues secret or
> protracting it.
This is definitely not true. It is an extremely good idea to keep
security issues secret *for a limited period of time*, just long enough to
coordinate a response so that fixed packages are available, if it is
believed that the bad guys don't already know about the security
vulnerability. (If, for example, it was found in a code audit.)
Security issues are always a race between upgrading systems and automating
exploits. Providing the information required for automated exploits
before fixed packages are even available for installation is a bad idea,
if by waiting for a few days one can coordinate fixed packages and give
system administrators a fighting chance to update their systems.
This should not come as a surprise to any Debian Developer. See, for
example, the instructions in the devref for how to handle security
vulnerabilities, which involve giving the security team a chance to
prepare an advisory *first*.
Obviously, the situation changes if there's an exploit in the wild, but
many security vulnerabilities are found via code audits and the bad guys
don't find out about the vulnerability until the first security advisory
goes out. That appears to have been the case in this instance, for
example.
What you should not do is keep security issues secret *forever*, or
otherwise try to pretend they don't exist just because they weren't found
in a public way. As soon as one is discovered, a clock should start
ticking, leading inexorably to full public disclosure. But sending a
complete report of the vulnerability to public mailing lists immediately
isn't a good tradeoff. The goal is to maximize the security of everyone's
systems, which requires a combination of disclosure and preparation so
that people can reasonably *act* on the disclosure, and always involves
some degree of tradeoff between coordination and disclosure.
> And in this special case it was easy to fix the problem very fast when
> the advisory cames out.
Given that new libssl0.9.8 packages were already available, yes. If they
weren't, it would not have been at all easy for the average Debian user to
fix the problem, and any attacker would have been given a head-start on
those users.
> It is never a good idea to set a embargo period for a security issue.
I couldn't possibly disagree more, or more strongly, and this is certainly
not how Debian handles security advisories.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: