[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Final position RE: [CVEPRI] Handling new vulnerabilities disc overed by Steve Christey



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hahahaha...  This thread is the funniest thing that has come through
my inbox in quite some time.  Funnier than the hamster dance.
Funnier than George Lucas in Love.  Funnier, even, than the time that
a competitor (who shall remain nameless) sent me an unsolicited
message offering their anti-virus product "at a special price".

Steve's original question was whether or not there is a problem with
his discovering, assigning candidate numbers for, and releasing
security announcements for vulnerabilities.  To that original
question, I say "of course not."  If Steve starts making a habit of
releasing vulnerabilities sent to him as his own, people stop sending
vulnerabilities for candidate assignment.  I just don't see it as a
big threat.

That being said, the conversation then turned to the issue of the
source and motivation of advisory releases in general.  Speaking as a
member of an organization that includes finding new vulnerabilities
as part of its charter, I feel like I should chime in.  OF COURSE
there is an element of self-promotion involved.  Aleph, Marcus, and
Russ - bear in mind that not everyone in the industry is as
well-established as you are...  The only way for many of them to gain
that recognition (and some of them certainly may deserve it) is to
make their work public.

When a security provider (whether it be tools or services) releases
an advisory, it tells their customers that they are actively looking
for new threats, and taking steps to eliminate them.  Marketing?
Maybe.

When an individual releases an advisory, it tells security providers
that they are looking for a job.  Marketing?  Almost certainly.

In all seriousness, though, the advisory also serves other purposes -
it keeps software vendors honest in getting quality patches released,
and it helps everyone (researchers and vendors alike) find and fix
potentially similar problems in other products - and isn't that our
ultimate goal?

Moving on to the issue of disclosure, I would like to share our
policy:  As a general rule, we notify vendors of a problem, and wait
until there is a patch.  If an exploit shows up in the wild and is
being actively exploited, we will release the advisory without a
patch and hopefully be able to offer suggestions for end users to
implement protective measures.  I would call this "responsible
disclosure", and I feel that most vulnerability research follows this
pattern.

Problems that show up in a public forum are a slightly different
animal.  Someone may post to *Bugtraq asking about strange behavior
or an apparent problem.  It may result in the discovery of a more
serious flaw.  Work-arounds may be suggested, and patches may be
developed, but there will most likely be a delay between the
discovery of the problem and a fix being available.  This, to me, is
life in the world of computer security.

When security researchers (either professionals or gifted amateurs)
"leak" a vulnerability in this manner, I consider it to be
irresponsible.  Most people who do any significant amount of research
will take the time to verify unusual behavior and contact vendors
before making any sort of public announcement.

Now, if you want to talk about improving the situation, then let's
start by making the process easier for security researchers to work
with the vendors in the first place.  A quick first step would be for
every hardware and software vendor to set up (and I mean today) a
"security@*.com" and/or "security-alert@*.com" e-mail box that is
assigned to someone in the organization.  I have, on several
occasions, spent a lot of time scouring newsgroups and war-dialing
DID's to find SOMEONE who could address a security flaw in their
product.  If it's easy to contact a vendor, and they are responsive
both to initial queries and to follow-up requests, I feel that most
people will be more than happy to work with the engineers involved in
producing a patch.

PLEASE NOTE:  I am not dismissing the responsibility of researchers
to provide clear, reproducible reports to the vendor.  I think that
this is very important and should be reinforced whenever possible.
The better the initial report/advisory, the easier it is for the
vendor to identify and (hopefully) fix the problem.

One step at a time.  A journey of a thousand miles... etc, etc, etc.

So.  That's my take, for what it's worth.  Are we saving the world?
I don't know, but I hope we're helping to make it a safer place.

- - Jim

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1
Comment: Crypto Provided by Network Associates <http://www.nai.com>

iQA/AwUBOcv66gDjeqNVcQB5EQIXCwCg/kZzDHWkvb+304ei6D4DJCkrCFwAoNzY
q792rWRfonk6KBoW5+WfCevC
=UirR
-----END PGP SIGNATURE-----

Page Last Updated or Reviewed: May 22, 2007