Re: Bug#129604: general: Social Contract: We Do Hide Problems
Fabian Fagerholm <fabbe@paniq.net> writes:
> On Fri, 2002-01-18 at 15:20, Lars Bahner wrote:
> > This doesn't cut the cheese. If, say, ``vsftpd'' i bugged with a remote
>> root exploit with no patch in sight then I want to know, so I can remove
>> this application system. I you know of such a hole and you are not
>> telling me, then you are hiding the problem from me. This simple and
>> really can't be argued.
>
> The problem is not that there exists a bug in the program.
No, actually that *is* the problem. If the bug did not exist, then a
discussion of who should be told about the bug is meaningless.
> There are many programs with bugs that do not fall under the
> category discussed here.
There are, however, no programs without bugs that fall into this
category.
> Those are different problems. The problem is that "evil" people
> might take advantage of the bug to cause harm.
True!
> The purpose of "security" in this context is to minimize the
> possibility of that happening. I can't imagine how disclosing
> detailed information on a root exploit before having removed the
> possibility of someone using that exploit to cause harm, can
> minimize the possible harm done.
Well, consider the case of a bug which has an exploit in the wild.
Assuming then that the black hats are relying on Debian security
advisories to disseminate knowledge of the bug, is not wise (we know
that they have their own channels for propagating knowledge of
exploits).
Then, you have 2 possible alternatives:
1) the black hats know everything, the white hats know nothing
2) the black hats know everything, the white hats know everything.
In which case, I fail to see how keeping the good guys ignorant helps.
Even without a fix, sysadmins might be able to use the information to
shut down unnecessary systems, or come up with a work-around for their
particular situation (e.g. with a bug in apache that allows an
intruder to use cgi scripts that do some (legal) thing to gain root
access, a general fix might take time to write, but with full
disclosure, a sysadmin can patch her CGI scripts to not be vulnerable,
or if her website is mostly static content, disable CGI scripts).
Keeping the knowledge of a bug secret is beneficial if:
a) there is reason to believe that there is no exploit in the wild
(such that security advisories may serve as the main means of
propagating information about the bug to the black hats)
and
b) the expected time to a fix is short. The longer you wait, the more
you're betting other people's systems on there not being an exploit
in the wild. Once you tell them, then they can make their own risk
assessments (shutting down the program, or a work-around, may be
perfectly acceptable for some people).
I personally wouldn't go so far as to say that keeping something quiet
is *never* appropriate, but I'd say that prompt and full disclosure is
appropriate at least as often.
Now if information on the bug comes from a list which makes
non-disclosure (before it's patched) a precondition of joining, then
clearly, not disclosing it is appropriate.
[...]
> What should the locksmith do? Should he post a notice in the town
> newspaper that states the lock isn't safe, and describe how it can
> be opened without the correct key, possibly drawing thieves to try
> and steal the cattle while the insecure locks are in use? Or should
> he develop a fix as soon as possible and have fixed locks or a
> fixing kit available in his shop - and then make the issue public?
Well, that depends on whether there is a significant risk that the
thieves will also discover (or have discovered) the flaw in the lock
before the locksmith has a fix (so I can take appropriate steps,
posting guards till the fix is available, or whatnot).
-Eric
Reply to: