From: mattmurphy at kc.rr.com (Matthew Murphy)
Subject: Vulnerability Disclosure Debate

To list: My first message was clipped.  My apologies!

> Some good points.. HOWEVER, in todays world, we must balance the right
> of users to know EVERY DETAIL about the exploits that could be used
> against them, with the fact that the hackers generally ALREADY KNOW
> these details.

In some cases (MS03-007, for instance), that is correct.  However, in most
cases, you'll find that this is false.  It does hold true that in cases
where a public advisory was the first awareness of the exploit, that it
would have
*eventually* been discovered by a malicious third-party.

> If a company that manufactures locks does a poor job and
> a locksmith publishes how to break into the lock, that should be
> considered a service to all.

Oh really?  I wouldn't be rushing to thank the locksmith, I'd be thinking,
"Oh shit, how do I keep my house from being broken into?!".  This analogy is
somewhat flawed.  You see, with a lock, the primary purpose of it is
security -- it has no other purpose.  Networked applications are an
inherently insecure technology -- they are built as matters of convenience
or of other requirements than personal security.  In any case, such a
philosophy leaves the user with a hole exposed and no way to plug it without
breaking accessibility somewhere.

Now, if that same locksmith reveals the details of that problem, and offers
an intermediary fix, then I'd be thankful.  If there is a good workaround
available, this philosophy becomes more feasible.  Now, I must also stress
that the workaround requires a solid *distribution mechanism* that will
allow most users to know of the vulnerability, so that they can actually
implement the fix.  Unfortunately, the best avenue for this remains with
vendors, and media.  Vendors typically want to wait until they have a code
fix so that customers don't complain, and unless it's really serious, media
won't pay attention without a major vendor press blitz, and even with such,
there is only one vendor that I'm aware of that can do that -- Microsoft
(and only because of almost complete market dominance).  So, without a good
channel for notification, even the best workaround is quite useless.
Another problem is that security-specific channels (like this list) are not
understandable for the common user -- the types that get every mass mailing
worm under the sun, and that we all hate to work with.

The only other worthwhile notification channel for the majority of home
users remains government (usually also accomplished with some media
influence).  In the case of a defective lock, a government ordered recall
would be likely, as the entire purpose of the lock was violated.  My, all
this talk about picking locks makes me happy to have a deadbolt! :-)

> After all, how can consumers make good
> choices without ALL of the information? Yeah, some will misuse the
> information.. but users have the RIGHT to know how secure (or in the
> case of Windows insecure) the product they are using is.

I agree that users have a right to know how secure their systems are.
However, measures of individual vulnerabilites have historically proven poor
as tests of actual product or vendor security.  Measurements like attack
surface (potential points of exposure when configured in least secure mode)
are better indicators.

> They also have
> the right to know how DIFFICULT it is/was for an attacker to actually
> perform the attack (this includes code samples to test the concept
> themselves if they want - unless of course you expect every user to be a
> coder). Keep Disclosure FULL DISCLOSURE ... lock picks should be legal
> both in society and in cyberspace.

Once again I agree with the idea, but not the method.  Releasing exploit
code for every vulnerability eliminates the notion of difficulty to exploit,
as every vulnerability is just point-and-click, regardless of how difficult
it was to actually write the exploit.  Unless of course, you expect every
user to be a coder.  If a user truly wishes to be security aware, exploit
code does not help this goal, as 99% of users cannot understand it enough to
actually determine the technical details involved.  To be security aware
about a product, users should understand vulnerabilities in general,
especially previous issues with that product and/or its competitors.  By
looking at the details of such, it is much easier to determine difficulty
than by blindly rooting your entire subnet.

Powered by blists - more mailing lists