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:
pgpb5ohXJhkY3.pgp
Description: PGP signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/