Re: Seeking comment on disclosure articles

[Valdis.Kletnieks () vt edu]

On Fri, 12 Jan 2007 14:34:21 +0100, Ben Bucksch said:
> These are the ground rules. There may be reasons to immediately publish 
> without pre-notification, e.g. when the bug is too obvious. Under no 
> circumstance should a fix take longer than one month.

Oh, do we wish it were so...

Yes, there's no excuse for trivial stuff (most bugger overflows, etc) that
only require a few-line change to take very long to verify the bug, code a
fix, and do the regression testing.

However, sometimes a bug is more difficult to fix, and hard choices need to
be made.  If it's something like a race condition that causes a TOCTOU issue,
or involves the interaction of several API elements, things get interesting.
You may find that there *is* no easy or good fix that doesn't involve the
breaking or changing of a published API used by external programs.

And then the fun starts - you have to make some *really* tough decisions.
Do you ship the fix, *knowing* that in all likelyhood it will cause a
mysterious and hard-to-debug failure on at least 10% of customers if they
don't rework their applications, or do you think about it for another week,
knowing that likely, only 1% at most of customers are likely to be hit by
the exploit?

Google around for 'GDI SETABORTPROC' - there's an example of a broken-by-design
API, that the only way to really fix it is to take it out back and shoot it.
Now tell me quickly - how do you find and notify all the *legitimate* users
of that API that they need to fix their stuff?  And sometimes, it's not
easy to do - how many times have we seen a validation error in some image
library or similar code, and then for the next 6 months we see *more*
advisories against other programs that carry their own statically linked
versions along?

And then, there's just the fact that your 2-3 line fix may not be as obviously
correct as one might hope...

http://www.securityfocus.com/bid/1480/discuss - an interesting beast. The
fun part of this one is that the vulnerable syslog() call was specifically
added to log attempts to exploit an earlier vulnerability.  Whoops.  Sometimes,
you want to take more than a week to double-check your code and regression-test.

Attachment: _bin
Description:

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/