full-disclosure - Re: Seeking comment on disclosure articles

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200701130755.l0D7tKEa021871@turing-police.cc.vt.edu>
Date: Sat, 13 Jan 2007 02:55:20 -0500
From: Valdis.Kletnieks@...edu
To: Ben Bucksch <news@...ksch.org>
Cc: Shawna McAlearney <SMcAlearney@....com>, full-disclosure@...ts.grok.org.uk
Subject: Re: Seeking comment on disclosure articles

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.

Content of type "application/pgp-signature" skipped

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