> > It seems that recently a meduim security hole was exposed in mozilla: > allows a server to read local files. > [snip] > Anybody here happens to know more about the ways in which GreyMagic tried > to inform Netscape of this flaw (according to ther advisory)? The bugs in > the bugzilla were only opened (immediatly) after the annoncement of this > advisory. >
>From my experience when submitting security holes to vendors, it is sometimes more difficult to get an answer from the vendor (or even understand who to notify) than to actually find the security hole. Since we're in the security business and not the vendor-notifying business, I would rather my people spend time and effort searching for security holes rather than trying to understand how the specific bug submitting system of the vendor works, and who they should notify about security holes. But I think the following post to ntbugtraq says it better: ----- Original Message ----- From: "Steven M. Christey" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 02, 2002 12:39 AM Subject: Re: Reading local files in Netscape 6 and Mozilla (GM#001-NS) > On Bugtraq, Rui Miguel Silva Seabra <[EMAIL PROTECTED]> 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-0 0.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, > [EMAIL PROTECTED] > > 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. > -- Aviram Jenik Beyond Security Ltd. http://www.BeyondSecurity.com http://www.SecuriTeam.com Know that you're safe: http://www.AutomatedScanning.com ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
