[Full-Disclosure] Re: it's all about timing

From: Steven M. Christey (full-disclosure@lists.netsys.com)
Date: 08/01/02


From: full-disclosure@lists.netsys.com (Steven M. Christey)
Date: Thu, 1 Aug 2002 01:45:46 -0400 (EDT)

The Responsible Disclosure Process draft specifically allows for
researchers to release vulnerability information if the vendor is not
sufficiently responsive. Some people may disagree with the delay of
30 days between initial notification and release, but I don't think
there are good stats on how long it really takes vendors to fully
address vulnerability reports - open or closed source, freeware or
commercial. Let's take a recent example - how much coordination had
to happen for the zlib vulnerability? It seems reasonable to assume
that it took more than a day. And the controversial "grace period"
has the interesting distinction of being used by both Microsoft and
Theo de Raadt.

Researchers can help to shed light in this area by publishing
disclosure histories along with their advisories. (By the way, vendor
advisories rarely include such information.)

While the response to the proposal focused almost exclusively on how
it impacts researchers, it lays out a number of requirements for
vendors, primarily that they (a) make it easy for people to file
vulnerability reports, (b) be responsive to incoming vulnerability
reports, and (c) address the issues within a reasonable amount of
time.

IMHO, it makes a stronger impression when someone releases a security
advisory with an extensive disclosure history that says how much they
tried to resolve the issue with the vendor, before they released.

Those who are interested in the legal aspects of "responsible
disclosure" are encouraged to read the article by Mark Rasch at
http://online.securityfocus.com/columnists/66. The article basically
says that the adoption of community standards could protect
researchers who disclose issues responsibly, while it could also help
vendors who seek legal recourse against researchers who are not
responsible (for some definition of "responsible"). The former could
happen with a community standard. The latter may already be happening
without one.

This email is my personal opinion, not my employer's.

- Steve
(co-author of the aforementioned Responsible Disclosure proposal,
which is presently quiet but not dead, but will always be subject to
public feedback)



Relevant Pages

  • Re: [Full-Disclosure] No Subject (re: openssh exploit code?)
    ... out response to my views and my statements. ... need for the disclosure of exploits. ... > remote exploitable vulnerability in network service code makes it next ... >> recognises the potential impact of releasing it. ...
    (Full-Disclosure)
  • Open-Xchange Security Advisory 2013-03-13
    ... The vendor has chosen responsible full disclosure to publish security issue details. ... Vulnerability Type: Cross Site Scripting ... Internal reference: 24649 ...
    (Bugtraq)
  • Re: Using 0days as part of pen-test?
    ... the client the option to determine how the vendor gets notified. ... vulnerability information you discover during ... The legal issue isn't the disclosure process, you can act as "legal entity" ... security threats until the vendor release a patch. ...
    (Pen-Test)
  • [Full-disclosure] CORELAN-10-035 NolaPro Enterprise multiple vulnerabilities
    ... Vendor: Noguska LLC ... SQL Injection, Cross-Site Scripting, Information Disclosure ... Vulnerability discovered by: ekse ...
    (Full-Disclosure)
  • Re: Call to arms - INFORMATION ANARCHY
    ... Its one thing to prove to a Vendor they have a problem in their code. ... and its not resolved by keeping "Full Disclosure" alive. ... the Vendor for a vulnerability without accepting responsibility for your ... feed the feature versus security mentality of many Vendors. ...
    (NT-Bugtraq)