Security Group Proposal, Draft 6
Mitchell Stoltz
talking to some Netscape and Mozilla folks, I'd like to propose some
more changes to our security group proposal. I've attached a new draft
and diffs below.
The major change is some language about putting a Known Vulnerabilities
page on mozilla.org. The following is Gerv's idea, and I think it's a
good one. Our major sticking point with this policy seems to be how much
information vendors (and Mozilla) can disclose about a vulnerability
before it is fixed. To prevent any misunderstanding about that, when a
security bug (vulnerability) is filed, let's decide in the bug how much
information is safe to reveal immediately. Obviously, everyone who has
access to the bug will have input into this. Then we'll post a message
on a Known Vulnerabilities page, similar to what other open source
projects maintain. Then, any Mozilla vendor or distributor who wants to
inform their users about the existence of a bug can use the information
from the Mozilla page, but no more.
As module owner, I'd be happy to maintain that page, along with whoever
we pick as peers. As with the rest of this proposal, I expect that the
amount of information disclosed on the public page will be decided by
consensus among the security group on a per-bug basis.
The other change I made was to the language about disputes over when a
bug should be taken out of the security group. Instead of recommending
private negotiations between parties, we should emphasize open
collaboration on the security group mailing list.
Please let me kno what you think of these changes.
-Mitch
Mike Shaver
> Then we'll post a message
> on a Known Vulnerabilities page, similar to what other open source
> projects maintain. Then, any Mozilla vendor or distributor who wants to
> inform their users about the existence of a bug can use the information
> from the Mozilla page, but no more.
*kiss*
Mike
Frank Hecker
> In light of objections people have raised on the newsgroup, and after
> talking to some Netscape and Mozilla folks, I'd like to propose some
> more changes to our security group proposal. I've attached a new draft
> and diffs below.
Mitch, thanks for doing this. I'm still bogged down in writing stuff for
work, and haven't been able to do another draft myself. Thanks also to
you and everyone else for participating in the n.p.m.security discussions.
The only comments I have are concerning typos and style:
1. In addition to changing the document draft number, please change the
date in the document when/if you do any future drafts.
2. All occurences of the term "security group" should be changed to
"security bug group" for consistency within the document.
3. You have a duplicated word "on on" in one of the sentences right
before "www.mozilla.org".
4. Instead of "... on www.mozilla.org", please write "... on the
mozilla.org web site" and make "mozilla.org web site" a link to
"http://www.mozilla.org/".
Also, just to be sure nothing broke HTML-wise, please validate the file
at http://validator.w3.org for HTML 4.01 strict compliance if you
haven't already done so.
I'll rejoin the general discussions on n.p.m.security as soon as I have
spare time available; my apologies for my absence the past two or three
days.
Frank
--
Frank Hecker
hec...@mozilla.org
Ben Bucksch
> As module owner, I'd be happy to maintain that page, along with
> whoever we pick as peers. As with the rest of this proposal, I expect
> that the amount of information disclosed on the public page will be
> decided by consensus among the security group on a per-bug basis.
"Consensus" is such a thing. Do we have consensus on a security policy
for Mozilla? No.
>! <p>When a bug is put into the security group, the security
>! group members, bug reporter, and others associated with the bug
>! will decide, either through comments on the bug or the security group
>! mailing list, whether an immediate warning to users is appropriate
>! and how it should be worded. This warning should mention the existence
>! of a vulnerability, which features or modules are affected, and a
>! workaround, if one exists. The module owner, a peer, or some other
>! person they may designate will post this message to a
>! "Known Vulnerabilities" page, which will be maintained at a well-known
>! location on on www.mozilla.org. These messages will contain all of the
>! information that the security group has agreed to be safe for
>! immediate public disclosure. Mozilla distributors who wish to inform
>! their users of the existence of a vulnerability may repost these
>! messages to their own websites, mailing lists, release notes, etc, as
>! long as they don't disclose any additional details about the bug.</p>
>
That's much less than you said were OK in your last posts and much less
than I need. You now constrain the info I give my users to what you
publish for Mozillam, while yesterday, you said "You can inform *your*
users via your mailing list, release notes, etc, as long as you make an
effort not to provide enough information to allow someone to reproduce
the bug".
I want to issue warnings (to my users)
1. for *all* bugs I consider severe enough and
2. in I wording I choose, with content I choose (as long as I don't
disclose reproduction info or something close to it)
Rationale:
2., because my users are of course less technically savvy than Mozilla
contributors, and the workarounds are also likely to be different for
Beonex Communicator (different default settings, different install
strategy etc.). I might even need to reveal more (still vage) facts
about a bug than the official warning does, when I think that this is
necessary for my users to judge their risk and to work around the bug.
Reaching "consensus" also takes time, more time than is acceptable for
me in some situations.
1.: please try to understand my situation. I see a bug, know that users
risk their whole network security because of that buffer overflow, and,
for any reason, the reporter or the security group decides not to issue
a warning, so I am not allowed to warn my users. That's unacceptable and
cruel (sorry for the hard word, but that's how I feel about it).
If you want to prepare the warnings for mozilla.org, incl. their
wording, in the security group, that's certainly fine with me.
BTW: I wouldn't define a web-"page", because I think that
newsgroups/mailing lists are the best method to publish such urgent and
important info. Having the same info additionally on a webpage is surely
nice, though.
> <p>If disputes arise about whether or when to disclose information
>! about a security bug, the security group will discuss the issue via
>! its mailing list and attempt to reach consensus. If
> necessary mozilla.org staff will serve as the "court of last
> resort."</p>
>
Great!
Gervase Markham
> That's much less than you said were OK in your last posts and much less
> than I need. You now constrain the info I give my users to what you
> publish for Mozillam, while yesterday, you said "You can inform *your*
> users via your mailing list, release notes, etc, as long as you make an
> effort not to provide enough information to allow someone to reproduce
> the bug".
>
> I want to issue warnings (to my users)
>
> 1. for *all* bugs I consider severe enough and
If a bug is security-confidential, then some form of warning will be
agreed (unless none of the participants requests that one be agreed.) If
it's not, you can publish what you like. So, as I understand it, no-one
will prevent you from issuing a warning of some form.
On the other hand, take the GIF overflow bug in NS 4.77 as an example.
If we had a bug like that, are you really going to warn your users to
disable images? If not, there's no point in issuing any warning at all
until there's a fix available.
> 2. in I wording I choose, with content I choose (as long as I don't
> disclose reproduction info or something close to it)
I think that the answer to this is basically "you can't have it." Sorry
to sound cruel or harsh, but there it is. All vendors, including
Netscape, will publish only what the group agrees on. Why should you be
different?
> Rationale:
> 2., because my users are of course less technically savvy than Mozilla
> contributors, and the workarounds are also likely to be different for
> Beonex Communicator (different default settings, different install
> strategy etc.). I might even need to reveal more (still vage) facts
> about a bug than the official warning does, when I think that this is
> necessary for my users to judge their risk and to work around the bug.
> Reaching "consensus" also takes time, more time than is acceptable for
> me in some situations.
>
> 1.: please try to understand my situation. I see a bug, know that users
> risk their whole network security because of that buffer overflow, and,
> for any reason, the reporter or the security group decides not to issue
> a warning, so I am not allowed to warn my users. That's unacceptable and
> cruel (sorry for the hard word, but that's how I feel about it).
Let's look at the other situation. Neither you nor your users find out
about the bug because it's been filed in Bugscape. Netscape keeps it
quiet for as long as it likes, and meantime your users get shafted by
the skript kiddies exploiting it.
I'm not saying that this possibility allows Netscape to dictate the
terms of the entire security group proposal without discussion; I am
merely making the point that the usefulness of the group goes up with
the number of the participants, in proportion to what those participants
contribute. If Netscape feels it can't contribute because it can't be
sure you aren't going to shaft _their_ users, then they won't. And
everyone loses.
> If you want to prepare the warnings for mozilla.org, incl. their
> wording, in the security group, that's certainly fine with me.
> BTW: I wouldn't define a web-"page", because I think that
> newsgroups/mailing lists are the best method to publish such urgent and
> important info. Having the same info additionally on a webpage is surely
> nice, though.
I think Mitch is saying that the web page (which has checkin and change
control) is the master source, and anyone can disseminate whatever they
want wherever they want from that page.
Gerv
Jesse Ruderman
>which everyone in the security bug group will be subscribed.
>This list will act as the well-known address to which users can submit
>new security bugs.
How about having a sublist to which users can send reports of new security
bugs, so not all members of the list have to recieve all the spam?
>The original reporter of a security bug has the primary responsibility
>for deciding when that bug will be made public; disclosure is done by
>clearing the bug's "Security-Sensitive" flag, after which the bug will
>revert to being an ordinary bug.
> ...
>However we will ask all individuals and organizations reporting
>security bugs through Bugzilla to follow the voluntary guidelines
>below... Before making a security bug world-readable, please provide a
>few days notice to the Mozilla security bug group by sending email to
>the private security bug group mailing list.
Reporters are unlikely to care about the bug several months after it is
fixed, and are even less likely to care enough to ask permission to open it.
Reporters should have the *ability* to open bugs to the public, but they
should not be relied upon to make their bugs public several months after the
bugs are fixed. That responsibility should lie elsewhere (hi BenB).
Ben Bucksch
>How about having a sublist to which users can send reports of new security
>bugs, so not all members of the list have to recieve all the spam?
>
.../discussion.
Agreed. <secu...@mozilla.org> should be reserved for new reports, not
used for long discussion.
>Reporters are unlikely to care about the bug several months after it is
>fixed, and are even less likely to care enough to ask permission to open it.
>
Ex-act-ly.
>Reporters should have the *ability* to open bugs to the public, but they
>should not be relied upon to make their bugs public several months after the
>bugs are fixed. That responsibility should lie elsewhere (hi BenB).
>
Wave :).
Ben Bucksch
> If a bug is security-confidential, then some form of warning will be
> agreed (unless none of the participants requests that one be agreed.)
What if not? What if it takes too long? What if it's inappropriate for me?
> On the other hand, take the GIF overflow bug in NS 4.77 as an example.
> If we had a bug like that, are you really going to warn your users to
> disable images?
Maybe. Maybe I'm going to warn them to possibly not use the browser at all.
> I think that the answer to this is basically "you can't have it."
Then I think my answer to this will basically be "Then I don't want to
play with you".
Weren't we talking about consensus?
> I'm not saying that this possibility allows Netscape to dictate the
> terms of the entire security group proposal without discussion; I am
> merely making the point that the usefulness of the group goes up with
> the number of the participants, in proportion to what those
> participants contribute.
And I am saying that too "liberal" terms in the security bug group make
it useless for me, no matter if anybody participates or not.
> If Netscape feels it can't contribute because it can't be sure you
> aren't going to shaft _their_ users, then they won't.
How am I going to "shaft" their users??
> I think Mitch is saying that the web page (which has checkin and
> change control) is the master source,
Which I think is wrong. You cannot ask me to reload the page every 3
hours, if I want to be sure to get the latest warning.
Gervase Markham
> Gervase Markham wrote:
>
>> If a bug is security-confidential, then some form of warning will be
>> agreed (unless none of the participants requests that one be agreed.)
>
> What if not?
If you ask in the bug for the participants to agree a warning text, one
should be agreed. If you want that stated in the policy, say so - but it
seems like common sense to me.
> What if it takes too long? What if it's inappropriate for me?
You have to raise those concerns in the group. Others may share them. A
form of words will be reached. This is consensus :-)
>> I think that the answer to this is basically "you can't have it."
>
> Then I think my answer to this will basically be "Then I don't want to
> play with you".
That would be unfortunate, as I believe your users would lose out if you
were not a member of the security group.
> Weren't we talking about consensus?
We were. But it appears we have reached an impasse. You will not accept
being told what you can and cannot say by the security group; Netscape
will not accept you being permitted to say whatever you like and perhaps
hurting their users by being over-generous with vulnerability information.
If you claim that the latter could never happen, then you should have no
objection to saying only what is agreed by the group.
>> If Netscape feels it can't contribute because it can't be sure you
>> aren't going to shaft _their_ users, then they won't.
>
> How am I going to "shaft" their users??
As I understand it, the entire reason that this web page announcement
proposal has been put forward is so that a member of the security group
does not (advertently or inadvertently) reveal information which leads
to trouble for the users of other members' software. This is why what is
said must be agreed upon.
>> I think Mitch is saying that the web page (which has checkin and
>> change control) is the master source,
>
> Which I think is wrong. You cannot ask me to reload the page every 3
> hours, if I want to be sure to get the latest warning.
You as a distributor of Mozilla-based products, or you as an end-user?
As a distributor, you will be a member of, and active in, the security
group and involved in any discussions which lead to a post on the page.
As an end-user, you should not be referring to that page at all, but to
whatever mechanism the distributor of your software has for notifying
you of security problems.
Gerv
Ben Bucksch
> Ben Bucksch wrote:
>
>> Gervase Markham wrote:
>>
>>> If a bug is security-confidential, then some form of warning will be
>>> agreed (unless none of the participants requests that one be agreed.)
>>
>> What if not?
>
> If you ask in the bug for the participants to agree a warning text,
> one should be agreed.
I'm talking about a case where a strong party disagrees that *anything*
at all should be make public. E.g. Netscape or someone else finds the
GIF buffer overflow you mentioned, and Netscape doesn't want to have any
warning made by any vendor.
> If you want that stated in the policy, say so - but it seems like
> common sense to me.
You mean that there will *always* be a meaningful warning, if *I* (i.e.
any participant in the security bug group) want to? If you write that in
the policy, that'd be good.
[part cutted - I'd only repeat myself, if I replied.]
>> Weren't we talking about consensus?
>
> We were. But it appears we have reached an impasse.
Right. Not only can't I get my views reflected (forced disclosure, even
if unfixed, after a certain amount of time), it seems like I have to
fight very hard for my absolute minimun requirements. I have no
experience in these things, but I think that's usually the point where
either the other party agrees or the fighting party leaves the negotiations.
> you [...] perhaps hurting their users by being over-generous with
> vulnerability information.
>
> If you claim that the latter could never happen, then you should have
> no objection to saying only what is agreed by the group.
The latter assertion is wrong. I am concerned that a strong party in the
group deliberately blocks or obfuscates the warning in order to hide the
bug.
>> How am I going to "shaft" their users??
>
> As I understand it, the entire reason that this web page announcement
> proposal has been put forward is so that a member of the security
> group does not (advertently or inadvertently) reveal information which
> leads to trouble for the users of other members' software. This is why
> what is said must be agreed upon.
blabla. Please explain, concretely, how Netscape's users would be harmed
by me informing my users about security holes in Beonex Communicator /
Mozilla. (No concrete reproduction info, of course.)
>> You cannot ask me to reload the page every 3 hours, if I want to be
>> sure to get the latest warning.
>
> You as a distributor of Mozilla-based products, or you as an end-user?
As whoever needs to know what is on the page.
The page is intended for mainly Mozilla contributors.