Re: In reply to comments about new policy

[dsiebert () icaen uiowa edu (Doug Siebert)]

John DiMarco <fdd () cdf toronto edu> writes:

> Surely there is a third way: time-lapsed full disclosure. When a problem is
> discovered, don't announce it until there's a patch, then announce the problem
> and the patch together, without exploitation information. 
>
> After a suitable time (weeks?) has passed, the rest of the information can be
> announced.  But don't post scripts to exploit the bug; it gives root to too
> many newbies.
>
> Announcing: "there's a problem here, go bug your vendor" isn't very helpful. 
> Announcing: "there's a problem here; here's how to use it to become root" is
> dangerous, because you set up a race between sysadmins and hordes of newbies
> all trying to exploit the bug before it is patched.


I'd think of "time-lapsed full disclosure" as:

1)  Bug is found and 8lgm and vendor(s) notified.
2)  8lgm posts notice of bug and any possible fix/workaround/patch if known.
3)  After a few days for simple easy to fix bugs (i.e. chmod -s crash since
    non-sysadmins don't/won't need to run it anyway) up to maybe a month for
    more difficult bugs (kernel divide by zero gives root) a full explanation
    and exploit scripts are published.

The only problem I see with this from my point of view is that when the
exploit scripts are published, other systems may be found that are vulnerable
that weren't known at the time.  But I'd rather err on the side of too much
information than too little.  I suppose this would leave a role for the
so-called "in crowd" like Gene Spafford -- they might get early access to the
details and exploit scripts and could test other systems for the bug.  If
additional systems are found vulnerable those vendors could be notified as
well and an update to the previous notice be posted.

I side with those who would claim that Gene Spafford and his ilk should be
forced to come up with evidence that full disclosure does NOT force bugs to
be fixed faster, and that it DOES result in more breakins, rather than trying
to put the burden of proof on the full disclosure crowd.  You should be forced
to provide a reason for restricting information, and information should flow
freely otherwise.  I see the need for trying to hold off on full details and
exploit scripts the instant something is discovered, to keep complete idiots
who know nothing from running the script and causing problems, but the wait
time should be kept as short as possible so that any sysadmin who keeps up
with Usenet, a list such as this, CERT advisories, or vendor patch info would
have a reasonable chance at fixing this problem.  If someone isn't keeping
up, too bad for them.  I don't want to suffer because they are lazy and/or
overworked, neither are my problem.


-- 
Doug Siebert
dsiebert () isca uiowa edu