Re: oracle not only offeder - researchers NOT responsible?

[Florian Weimer <fw () deneb enyo de>]

* Gadi Evron:

> He shows specific cases and vulnerabilities, and is worth a read. Quite 
> Refreshing and very informative.
>
> http://blogs.securiteam.com/index.php/archives/133

Informative?  The part about "CERT" (I think CERT/CC is meant) is
misinformed at best because CERT/CC shares vulnerability information
with non-vendors without compensating the submitter:

| Q: Who gets the information prior to public disclosure?
| 
| A: Generally, we provide the information to anyone who can contribute
| to the solution and with whom we have a trusted relationship,
| including vendors (often including vendors whose products are not
| vulnerable), community experts, CERT/CC sponsors, and sites that are
| part of a national critical infrastructure, if we believe those sites
| to be at risk.

<http://www.cert.org/kb/vul_disclosure.html>

(From what I know, "national critical infrastructure" does not include
the U.S. Internet, which is bizarre.)

The Lynn incident shouldn't be generalized because if vendors and
security consultants (I hesitate to call them "researchers") are so
close, the results hardly ever end up on BUGTRAQ (or in some kind of
public advisory).  Shawn V. Hernan wrote at the beginning of 2002,
regarding responsible disclosure:

| The whole idea of disclosure at all is not universally accepted.

<http://jis.mit.edu/pipermail/saag/2002q1/000464.html>

And I doubt that much has changed.  Where are the advisories for SS7
switches?  Juniper routers?  SAP software?

Let's face it: Most exploitation occurs after the issue has been made
public.  Whether the disclosure was coordinated in some way, or the
discoverer just went ahead and posted to BUGTRAQ, doesn't seem to make
a fundamental difference.  My own conclusion (which may well change
again 8-): Do not actively look for security bugs in _software_
(deployments are different matter; in practice, no one cares about
software vulnerabilities anyway), unless you aim for zero defects and
it's practical to achieve this goal.  Help the vendor to quietly fix
security bugs you have discovered accidentallly (if they aren't
completely clueless).  Do not create a self-fulfilling prophecy by
publicly labeling a vulnerability as particularly dangerous.  Downplay
it as much as possible when talking to the press.

The vendors aren't particularly supportive, though.  If I report
something, I'm expected to do the hard work: keep the process going
(pinging the vendor from time to time if there's no progress), write a
clean exploit, deliver a list of affected products, etc.  Sometimes,
this is even more work than the actual fix, especially if regression
testing is automated and you can test the fix together with another
change which is already scheduled.

After some time, it might be a good idea to publicly document
vulnerabilities fixed in the past, so that developers can avoid making
the same mistake ("misuse cases").  But this is not necessary for each
and every buffer overflow vulnerability.

In an abstract sense, I'm much in favor of full disclosure (mainly
because it keeps honest vendors honest), but at some point, you need
to concede to reality.
_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.