On Bugtraq, Rui Miguel Silva Seabra <rms1407.org> said:

>so much rant about not receiving any contact from Netscape (AOL
>subsidiary) or about not even giving prior notification to the
>developers about the bug AND, all in all, no one even posts to a
>bugzilla entry on bugzilla.mozilla.org which is the best place for bug
>reports on Mozilla (ie, *not marketdroid webpages*).
>
>This is either ignorance of bugzilla (bad but I can understand that),
>or intention to difamate the mozilla developers, which is very bad,
>since a lot of them dedicate their free time on providing us an
>extremely standards compliant, Free Software, cross platform web
>browser, and so we actually owe them a favour (so to speak).

There is another possibility: that this is one instance of a larger
problem with disclosure procedures in the security community.

There is no commonly accepted method for reporting and responding to
security bugs. Neither are there clear guidelines for how vendors can
make it easy for someone to report a security bug. Every vendor has
their own unique way of handling security reports and being accessible
to vulnerability reporters.

This inconsistency can make it difficult for vulnerability reporters
to contact the vendor, and some reporters feel forced to publicly
release a bug in order to get the vendor to respond. Many other
examples can be found in the Bugtraq list archives.

The proposed Responsible Vulnerability Disclosure Process (RVDP)
document provides specific guidelines to vendors to make themselves
more easily accessible to vulnerability reporters:

http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosure-00.txt

Sections 3.3.1 and 3.4.1 outline vendor responsibilities for the
Notification phase of vulnerability disclosure.

Those sections make the following suggestions (and several others):

- a standard security e-mail contact

- a prominent "security" web page that says how vulnerabilities should
  be reported

- providing a facility for someone who is not a "customer" to report
  vulnerabilities without requiring a support number or user
  registration.

The document also specifically suggests that vendors recognize - and
plan for - cases in which inexperienced or malicious vulnerability
reporters may not use the proper notification channels.

Future versions of the document will likely include additional
recommendations to vendors.

NOTE: IT MUST BE STATED THAT THESE TYPES OF PROBLEMS ARE *COMMON*
ACROSS MANY VENDORS, INCLUDING THOSE VENDORS WHO ARE PREPARED AND
WILLING TO RESPOND TO VULNERABILITY REPORTS.

Following are some observations of the Mozilla web pages:

  http://www.mozilla.org
  http://www.mozilla.org/quality/bug-writing-guidelines.html
  http://www.mozilla.org/quality/help/bugzilla-helper.html and
  http://bugzilla.mozilla.org:

These web pages offer some good examples for discussion.

1) The pages do not advertise a security contact (but many vendor
   sites do not)

2) The "Report a Bug" and "bug writing guidelines" pages do not
   describe procedures for reporting security bugs. (but many vendor
   sites do not)

3) In addition, the bug report's "Severity" menu does not allow the
   reporter to mark a bug's severity as "vulnerability" or "security"
   (but many vendor sites do not).

4) There are no occurrences of the terms "security" or "vulnerability"
   on these pages.

5) The reporting of a bug requires user registration (step 1 says to
   create a Bugzilla account). A number of vendors require
   registration or support numbers for reporting vulnerabilities,
   which makes it difficult or impossible for some vulnerability
   reporters.

6) A search for "vulnerability" from the search engine at
   http://www.mozilla.org/search.html *does* lead one to the Mozilla
   security bugs policy:

   http://www.mozilla.org/projects/security/security-bugs-policy.html

   However, it is unclear to me how someone might navigate to this
   page from other pages on the Mozilla site.

   This bugs policy (dated November 2001) says that:

     the mozilla.org Bugzilla system will allow bug reports related to
     security vulnerabilities to be marked as "Security-Sensitive,"

   which would be consistent with #3 above, although other followups
   to this thread imply that it's only for bugs that have already been
   reported.

   The bugs policy also says:

     Mozilla.org will maintain a second well-known address,
     securitymozilla.org

   which would address item #1.

Indeed, Mozilla's Security Bugs page outlines an extensive set of
procedures for how Mozilla handles and releases vulnerability
information. This statement - which is rare for vendors - covers many
of the other recommendations that are made in the current RVDP
document. Indeed, RVDP section 4.1 suggests that all vendors
implement such statements. The "Mozilla security bug group" is an
example of a "Security Response Capability" as described in RVDP 3.1.

It appears that my difficulty in finding a security contact on the
Mozilla web page was only due to a few missing links or other web site
design choices. Mozilla has clearly done some extensive thinking on
how to handle disclosure.

Now on to a related topic... On NTBUGTRAQ, GreyMagic said:

   In our submission to Netscape we specifically said that we plan to
   wait 5 days, not 5 business days, for a reply from Netscape. Is a
   simple reply too much? ... Since the ORIGINATOR is in Israel,
   Sunday is a business day like any other.

Because there are many different concepts of business days across the
world, as well as different holidays, RVDP 3.4.1 number 2 says:

   2) The Vendor MUST provide the Reporter and involved Coordinators
   with a Receipt within 7 days.

We chose 7 days to allow for global variations in work weeks and
holidays. That way, neither the reporter nor the vendor has to
"guess" what the other's schedule is. 5 days does not allow for
"weekends."

Note: the "Receipt" is a message from a human representative of the
vendor that indicates that the vendor is aware of the report. This
does NOT mean that the vendor must have been able to replicate or
resolve the issue at that time.

GreyMagic illustrates what other reporters have said in the past, and
what RVDP 3.4.1 is trying to address:

   We never expected an immediate "payoff", all we asked for was a
   little acknowledgement that Netscape received our post and that it
   is being handled.

Even when the vendor initially responds to an issue, too often the
communication is not maintained, and a reporter feels forced to
disclose the vulnerability before it has been fully resolved by the
vendor.

If the procedures for vulnerability reporting remain as inconsistent
as they are today, we will continue to see people reporting
vulnerabilities to the public before a fix is ready.

Vendor accessibility and responsiveness will not address every
disclosure situation, but it would make it easier for the many
vulnerability reporters who want to work with vendors to resolve an
issue before notifying the public.

- Steve

P.S. While the RVDP document is not being moved through the IETF any
more, Chris Wysopal and I remain committed to improving it and seeking
its adoption throughout the security and IT communities.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]