Re: FORCED RELEASE NOTES - CORE-090400 - BID 1634

[Warner Losh <imp () VILLAGE ORG>]

In message <Pine.GSO.4.21.0009041729390.17003-100000@mail> Vulnerability Help writes:
: That being said, there really is no one to blame for this situation. There
: exists no forum for competing vendors to share information like this and
: further many vendors simply don't seem interested in working with other
: vendors to see multi vendor vulnerabiltities resolved.

I know that various groups in the past have tried to strike a balance
between vendor coordination and forcing a release to spur the vendors
into action.  CERT came down on the "don't disclose until fixes are in
place" side of things early and only later did they add the "or too
much time passes" clause.  At least that's how it appears from the
outside.  FIRST did a good job, but something weird happened along the
way and they stopped doing that.

What's really needed is a vulnerability stamping service :-).  In the
coin collecting community, there are trusted parties that will encase
a coin in lucite and engrave the date and their "mark" to show that
this coin was encased in lucite on thus and such a date (or was given
to them to be so encased on the date, it varies).  This can be useful
in the coin collecting community to establish that a certain coin was
first of its type to enter circulation, etc.  Maybe something similar
is needed in the security community to strongly encourage advisory
writers from acting prematurely because that's the only way to call
"dibs" on a given vulnerability.  For it to be truly effective it has
to be done on a massive scale and get the word out to everybody in the
community.  It won't help people that release these things just to
cause trouble, but it might take some of the pressure off.

Warner