Re: Bug#129604: general: Social Contract: We Do Hide Problems
On Sat, 2002-01-19 at 00:30, Eric E Moore wrote:
> > 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.
True and true. I should have said something like the following:
After the bug has come into existence, and after someone has discovered
that the bug can be exploited to breach security in the system it is in,
the problem of security is a related, but separate problem - the problem
that someone may use the exploit to cause harm. As such, that problem
may be fixed without fixing the bug, for example by preventing the buggy
code from ever running (disabling the insecure program). The bug itself
does not cause harm, it only provides the opportunity for some human to
cause harm.
The point was that the goal of security is to minimize possibility of
harm done. Sometimes this is best done by fixing the bug, sometimes by
disabling the program, sometimes by immediate disclosure, sometimes by
delayed disclosure. It depends.
> 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).
Agreed. This of course raises the question of what the correct
definition for "short time to fix" is... This I regard as a personal
per-case choice. A good security manager has the skill to decide this.
In some cases, such as the non-disclosure-before-patch-list mentioned
below, the choice is not available, the terms of that list must of
course be followed.
> 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.
Absolutely. Such a list is a great asset and should not be misused.
> > 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).
I agree. The problem is, it is impossible to know whether or not the
thieves have this knowledge without asking them - which would
immediately lead to the condition that they do know about it, since the
locksmith just told them. Who the thieves are is another unknown issue,
not to mention the possibilities to reach them, and so on.
So the locksmith must choose.
If the thieves don't know, and the locksmith chooses not to disclose
until the fix is there, it was the correct solution (since the locksmith
did not provide the knowledge to the thieves - if the thieves find out
on their own before the fix is being made, this is no longer the correct
condition). No cattle was stolen and the security bug has been fixed.
The responsibility is shifted to the farmers - although the locksmith
should give any advice on the matter that he may have.
If the thieves don't know, and the locksmith chooses to disclose before
the fix is done, the responsibility is shifted partly to the farmers
(users of the lock) and they may protect themselves on their own.
However, there is a possibility that there are not enough guards to
post, and some cattle will be stolen anyway.
If the thieves do know, and the locksmith chooses not to disclose until
the fix is there, cattle will be stolen. This case is unlikely since it
is unlikely that the locksmith would have discovered the problem on his
own, in parallel with the thieves. Thus, the case would become public
when the first occurance of cattle stolen would take place. Cattle would
be stolen in any case, the issue would be public and the locksmith would
be best off making the fix ASAP while the farmers try to post guards.
The case that the thieves would know, and the locksmith chooses to
disclose is irrelevant, because the case is unlikely for the same reason
as the previous situation. It is only a special case of the previous
scenario, and shows that the locksmith has a good procedure for handling
these things. So he gives some general advice and then goes back to the
workbench to fix the lock, while the farmers gather up guards...
Oh well, that's it. Nice little story... :)
One last note to people who think delayed disclosure is a bad thing.
There is a way of looking at things that says you must always tell the
truth, and it is a lie not to tell even when no one knows to ask. Well,
in my opinion things don't always work that way, even if that is the
ideal solution. It is all about _intent_. If you delay the information
with the intent to let people do damage, then it's clearly against the
goals of security. However, if you delay information with the intent to
prevent an even bigger harm (than being a liar) from occuring, then I
would regard this as acceptable.
I would rather know what didn't hit me after it was prevented from doing
so, than know in advance and being hit anyway because I stepped right in
front of it.
Cheers,
fabbe
Reply to: