There's been some discussion of what Mozilla should do with security
bugs, and their fixes.

The following text comes from bug 28387:

------- Additional Comments From sha...@mozilla.org 2000-03-23 09:01
-------

Why is this bug Netscape-confidential?

------- Additional Comments From nor...@netscape.com 2000-03-23 09:47
-------

I've made this bug Netscape confidential as I have all open security
exploits
against the browser.

I hope you'll agree that having open exploits visible to all comers is
not the
right policy as more people begin using mozilla. I'll also agree that
Netscape-only isn't quite right--ideally it would be a set of trusted
people in
and out of Netscape that would have visibility access to open security
exploits.
It's a pain for instance that Georgi Guninski, who works from Bulgaria
and thus
doesn't have Netscape-only access, can't even see the bugs he's found.

Once exploits have been fixed and the fixes have had time to propagate
to enough
users, then the bugs should be open for all to view. I had been
switching bugs
over from Netscape Confidential to open once they were fixed, but now
even after
I fix bugs in the tip I've been leaving them Netscape Confidential since
the
bugs are present in the soon-to-be-released beta.

We could push mozilla.org to create a new category of visibility for
security
bugs and let them maintain a list of trusted viewers. I hadn't pushed
for this
because I wasn't sure the extra effort was worth the gain.

------- Additional Comments From sha...@mozilla.org 2000-03-23 10:01
-------

I think it's inappropriate for Netscape to be given special privileges
WRT
security bugs.  What about other users of the code, who might also be
shipping
product or beta that could contain these bugs?  They can't even _know_
about
this bug, or understand the motivation for code that you're checking
into the
Mozilla tree -- which they might or might not want in their product --
with the
current setting.  Why should the Mozilla community trust Netscape if
Netscape
doesn't trust the community?  (And why is it OK for _anyone_ at Netscape
-- plus
myself and perhaps a handful of other ex-Netscapers -- to see this?  Why
do they
deserve special trust, just because of their email address?)

I think that Netscape has ample opporunity to decide whether to fix
these bugs
in their beta, given that there are known fixes in hand.  If that is too
much
risk for the Netscape beta managers to take, then that is their
decision, and it
shouldn't impact the rest of the Mozilla community.

I personally believe that as soon as there is a fix, workaround or piece
of user
advice (``don't add bookmarks for javascript: URLs from untrusted
sites'')
that's sufficient to prevent or limit the danger, we shouldn't be
restricting it
at all.  (I think that restriction of vulnerability information should
only
occur in very dangerous, very specific cases, and it should probably
involve
discussion with st...@mozilla.org: this bug wouldn't be such a case, to
my mind,
but I'd have been happy to debate it with others.)

I also believe that people who are reporting bugs in Mozilla should be
reporting
them through Bugzilla.  If Georgi wants to report Netscape-beta bugs to
Netscape, that's his choice, but I think he should be working in
Bugzilla like
the rest of our bug reporters.

------- Additional Comments From nor...@netscape.com 2000-03-23 11:06
-------

Shaver: Yes, start a discussion on n.p.m.security. I agree that security
bugs
should have an audience wider than Netscape, I just think that there
needs to be
some secrecy surrounding known exploits in software that is in use. That
secrecy
benefits mozilla users and mozilla contributors and isn't a
Netscape-specific
benefit.

-----------------------------------------------------------------

I think we agree on the following points:
- keep security bugs relatively quiet (Security Group Only) until
  a fix is found, tested and committed
- Security Group needs to be different than ``Netscape only''

What's left to decide is, at least:
- how is the Security Group populated?

- what do we do once a fix is found?

- does our policy differ when we get to a ``production release'',
  versus our current not-yet-beta state?

I'll post with my thoughts on these topics in a reply, hopefully today.

Mike

--
256708.87 208576.27

Does this procedure change, and if so how, if the bug is first
discovered by someone posting an exploit to a web site, to Bugtraq, or
alerting CNET and other media, rather than going through Netscape
channels? If a bug becomes known to Netscape at the same time it does to
the whole world, as it often is, is there any sound reason why you would
not want external contributors to help you fix it so long as it involves
open source code? In some cases, the same people who find it may be the
ones who help you fix it or provide a patch.

There has been a history at Netscape of failing to respond to
security-related bug reports from the outside (in fact, there are
complaints about this on Bugtraq even in the past few days with regards
to an unacknowledged exploit in Enterprise Server - see
http://www.securityfocus.com/templates/archive.pike?list=1&date=2000-03-15& msg=38D2173D.24E39...@relaygroup.com).
My concern is that there seems to be no obvious way yet to advise
Netscape in a confidential manner about Mozilla security bugs (at least
on the mozilla.org site) when one is found, and given the spotty history
of acknowledging past problems, this shouldn't be ignored.

In the case of security bugs where there is a known workaround but no
permanent fix yet, I strongly agree that disclosure of such a workaround
(and public bug acknowledgement) should be made available immediately.

I'll probably want to comment on those, but I'll wait to see what others
have to say first ...
--
Kevin Hecht, Netscape Champion
College of Commerce and Finance, Villanova University
khech...@idt.net    Kevin.He...@villanova.edu
           http://idt.net/~khecht19/

There should be no ``Netscape channels'' for Mozilla security bugs.  If
someone reports a bug to Netscape about their branded derivative, then I
presume that Netscape would report that vulnerability to Mozilla if it
was in common code.  People should be reporting Mozilla bugs to the
Mozilla community (or some designated subset thereof), not to one
particular contributor/consumer.

(They would always have the right not to disclose those things, I guess,
but that would be absurdly bad community spirit.  Let's not even go
there.)

If the exploit is public, I don't think we need to go to any lengths to
protect our own discussions of it, especially because opener discussion
might help us get to a better fix, sooner.

More in my self-reply, when I finish with it.

Mike

--
264567.81 216020.61

Elsewhere, someone suggested that the security group could be the same
as the group of people who can confirm bugs.  This doesn't seem too
unreasonable.

Open up permissions on the bug to the general public after the next
milestone release containing the fix?

Dan

No, let's. I can nearly guarantee (based on past behavior) that unless
mozilla designates a small trusted group of security-concerned people
Netscape will never divulge information about a non-public exploit until 1)
they have a fix *AND* 2) there is available a release or patch containing
the fix.  Microsoft does the same thing. It is simply irresponsible to
expose your customers to UNNECESSARY risks from script kiddies who would
run with that information.

Define "public". Merely being found by a mozilla community member does not
count, as most responsible security-hole finders want to give the affected
developers a chance to respond and/or fix before exposing it to the world.
Such people usually bring in the press only as leverage to move
recalcitrant vendors because they, too, understand the goodness of trying
to get a fix before letting the cat out of the bag.

If there isn't a way to report these security holes privately to
mozilla.org I'm betting many of these folks will report them quietly via
e-mail to netscape first. And as mentioned Netscape will probably try to
keep the info under their hat until there's a fix.

This is kind of a bummer because Netscape has limited resources devoted to
fixing security holes. And one of those people was just promoted to
managing the entire javascript team, no doubt reducing the amount of time
he can devote to security work. Security experts working alone or for other
contributing companies are not able to help out nor protect their customers
when they don't know about these exploits.

What can mozilla.org do to assuage the fears of contributing companies like
Netscape that will encourage them to share security information more
broadly, but in a controlled way?

What can mozilla.org do to assuage the fears of responsible security-hole
finders that will encourage them to share the knowledge of expoits with a
group of mozilla developers rather than just with the main vendor (at this
point) Netscape?

Key words: assuage fears and encourage. Netscape has been burned too many
times on security holes, you aren't going to dictate to them. If they have
to I have no doubt they will pull security bugs out of bugzilla and set up
a parallel system if bugzilla proves too leaky. And that would be a bummer
and inconvenience for everyone.

-Dan Veditz

IMHO, all security bugs should be fully disclosed and open. In addition,
a post to n.p.m.security (and Bugtraq or something?) should be made
every time a security bug is found, to alert the developers outside.

By opening the bugs like that, yes, you do permit people to exploit the
bugs before the fix is found and even after that exploit the bugs of the
users of the older versions of Mozilla (because they haven't updated to
a fixed version yet).

That is the only disadvantage of opening up security bugs. Now, is that
disadvantage really that bad? I don't think so. The average user Joe
usually doesn't randomly surf Geocities, encountering malicious web
pages. Such a user usually browses major web sites that are quite
unlikely to contain malicious code. Now, an advanced user or a heavy
surfer usually understands that there is some risk in doing
"promiscious" or "unsafe" surfing (ehh, hard to define, but let's assume
that "unsafe" surfing is surfing on supsicious web pages potentially
containing malicious code).

Furthermore, in the past, when a security bug was found in Netscape Nav,
it was usually left open until the next version came out. Which was not
a day after. It wasn't even a week after. It was just that, a new
version. And because Netscape kept it all quiet, people that were
looking to exploit bugs usually cared enough to monitor security mailing
lists and newsgroups for discoveries of Netscape Nav bugs, meanwhile the
unalerted users continued on browsing, without any care. And perhaps,
due to the slow release process, it was OK for Netscape to keep security
bugs this quiet. But not with Mozilla.

We are stepping into open source here. And that means open bugs,
especially security bugs (altough I am fine with closed
Netscape-branded-version-specific bugs). One of the constantly touted
benefits of open source is really quick bug fix time (and it's not a
myth). Security patches or temporary work arounds for applications are
usually available within hours, a few days at the latest. Remember the
OOB DoS attack problem a few years ago? Fixes for Linux and FreeBSD were
issued in a few hours, while Microsoft took about three to four days to
release a fix of the problem.

So now are the benefits of having publicly open security bugs. Once a
security problem is found and is publicly announced, people that really
care and otherwise would have not contributed to the project (like an
experienced programmer that normally doesn't have the time) would
actually help out with the bug, quickly providing a fix or the work
around. It's a huge benefit. Netscape itself benefits from this, as the
bugs in its browser are plugged lightning fast now, using developers
outside of Netscape's own developer force, thus freeing them to do other
things. Netscape also gains a good sales point, stemming from the fact
that Microsoft takes days to release patches for IE.

Security through obscurity doesn't work well. Obscurity means it costs
some effort to "find". This effort is a barrier, making software more
difficult to exploit. However, this effort is a much greater barrier for
fixing things.

So open up those bugs! You *will* benefit!

My humble opinion,

Oleg.

I really hope that Netscape realizes that they don't have a monopoly on
security reports or fixes.  Georgi used to, IIRC, post to bugtraq before
fixed versions were available, and today we have reports of privacy
issues related to cache control
(http://www.linuxcare.com.au/mbp/meantime/) -- will Netscape even bother
to ship an update to address them?

Sure, but Microsoft is the only distribution point for IE.  We're in a
different world.

So it would be ``simply irresponsible'', then, to ship a beta with known
security holes, rather than respinning to take in-the-tree-and-tested
fixes that would protect said customers?  And yet I will protect to the
death Netscape's right to decide what's in their software.

What would Netscape say if mozilla.org told them ``don't release your
6.09 update with mention of the fixed holes, because Really Slow Vendor
Inc. hasn't published their fix yet''?  Surely they would think it
unreasonable to wait for some slower vendor to take an unbounded amount
of time in this area.

``The affected developers''.  Does the fact that I choose to build my
own Mozilla -- because I'm on a platform that Netscape doesn't care
about, or because I want MathML -- make me any less entitled to
knowledge about vulnerabilities in the software that I'm running?

WRT public: bugtraq is public.  A web page is public.  If you can get
the information without being a memory of
mozilla-security-super-spec...@mozilla.org or discovering it
independently, it's public.

Hey, check it out!  I'm proposing just such a system!

I'm suggesting that we have a set of people who handle incoming security
reports (The Security Group), and that this set is smaller than
all-the-people-who-can-reach-bugzilla.

Do you have suggestions as to what the criteria should be for membership
in the Security Reports?  (Criteria that are likely to be rejected
out-of-hand include ``Netscape employee'', ``paid to work on Mozilla'',
``signed a Security Group Membership form'', I think.)

Well, yes, that's sort of my point.  And I don't think that Netscape
should control that information, because, as Kevin points out, their
record on acknowledging and repairing security holes doesn't indicate
the kind of high-speed response that the open source community has come
to expect.

In fact, responsiveness to security and privacy concerns may well be a
market-differentiator for Mozilla derivatives, leading to a world where
people get most of their browser from www.wecareaboutyoursecurity.com
and just grab the Netscape AIM/PSM bits from the Netscape-branded
packages (if they trust them at all).

I don't know how to answer that question, until someone clearly
articulates where those fears come from, preferably as ultimate rather
than proximate causes.

I believe that people report security bugs to Netscape because only
Netscape can effect a fix for its users; that will no longer be the case
for the vast majority of bugs in Netscape 6, where J. Random could
respin a layout.xpi with the appropriate fix and get new bits into the
hands of any interested user long before Netscape even admits that
there's a problem.

(Currently, of course, the main -- nay, only -- vendor of Mozilla is
currently Mozilla, so there's obviously some mechanism for motivating
people to report to another entity.  Otherwise, Netscape wouldn't have
these reports, right?)

Mike

--
264485.57 162416.43

I agree with this proposal.

Well, here are some suggestions:

1. Start with an initial "Mozilla security group" composed of
contributors vouched for by the appropriate module owner(s) most
concerned with and knowledgeable about Mozilla security issues.

2. Expand that group over time based on recommendations from those
already in the group, whether on a consensus basis or through some sort
of semi-formal voting by people in the group (e.g., require a two-thirds
or three-fourths supermajority for approval).

I wouldn't immediately dismiss the idea of having new people sign some
sort of form in addition to whatever else they're required to do (just
as people must do prior to getting CVS check-in privileges). However the
fact remains that the only way such a group is going to work in practice
is if the people in it are trusted on a personal level by the other
people in the group, and if the group as a whole is trusted by Mozilla
vendors (including Netscape).

I don't know about this particular scenario, but it's certainly true
that some businesses and individuals will want rapid responses to
Mozilla security issues and will be willing to pay for that in one way
or another. I think we should definitely encourage businesses that want
to provide such services, whether they do it independently or under
contract to Mozilla vendors.

I studied Latin in high school, but you lost me a little bit on this
sentence :-)

In any case, I think that people are worried about scenarios where some
random person "out there" has a) access to Mozilla security bug reports
and b) a willingness to exploit them for malicious purposes. Even if the
group of people able to view security reports were restricted in some
way, some people would still worry about scenarios where a malicious
person managed to get into that group in some way.

That's why I think it comes back to trusting people on a personal level.
I think the level of trust should be comparable to that required of a
person given check-in privileges, because the levels of risk are at
least roughly comparable. (A malicious person checking in code can
actually do just as much or even more damage by inserting trojans, but
there's at least the potential for it to be caught through review.)
That's why I favor a model based upon some reasonable level of personal
trust being established, as opposed to either a semi-automated granting
of access or a mere signing of forms in the absence of any personal
relationships.

Frank
--
Frank Hecker            work: http://www.collab.net/
fr...@collab.net        home: http://www.hecker.org/

Yes, bugfinders usually posted to bugtraq to pressure Netscape and/or
Microsoft, but they also usually gave the company a week or few days head
start at finding a fix before going public.

Nowhere did I say it was bad to use public disclosure as a lever to budge
recalcitrant vendors. In fact, sadly, it is probably more the threat of bad
press that fuels the urgency of security patches than concern with
customers' safety. Giving notice that in X days the hole goes public would
seem to be a responsible blend of motivating the vendor, warning the
public, and minimizing the amount of time the public is exposed.

I'm not posting here as a Netscape spokesperson, ask them what they'll do.

Sounds great, I guess we are in violent agreement then. I thought you were
proposing that all security bugs should be 100% public bugs.

There is a case to be made for full openness on an open source
developer-oriented project. But I fear it would drive Netscape to hoard
information (they apparently felt badly burned by the way Sun handled Java
security hole knowledge, and some of those folks are still around). Until
Netscape is no longer the 800-lb gorilla on the project that is something
to worry about.

I don't know why you reject your last item, since that's pretty close
to how CVS access is handled. I was imagining responsible security
developers could nominate others for inclusion in the group. That
leaves the problem of how to seed the initial group and it might not
scale fast enough.

The major problem with any scheme: no way to judge newcomers who could
potentially be brilliant contributors or malicious neer-do-wells. Any
amount of process that could weed out the latter could easily discourage
the former.

One current drawback to the current bugzilla implementation is that bug
reporters can be blocked from their own bugs. That seems silly to me and
should be fixed. If someone feels the need to add information they don't
want the reporter to see they should open a new bug and make the old bug
depend on it. In an "open" bug system a reporter should always have the
right to see what's going on with what they've reported.

I think the current mozilla security bugs are in Netscape hands because
most of them have been found by testers hired by Netscape, and Netscape
prefers to handle them that way given the lack of other options. They
*could* have been filed in the internal "bugsplat" database, so I'd say
that's at least a hint that if there were a middle ground between Netscape
private and completely public that it would have been used.

Plus Norris said that explicitly in the bug that started this thread :-)

-Dan Veditz

As a systems administrator and security auditor, I would be kind of
iritated
if netscape went to hoarding security related bugs for multiple reasons.

1.      If a bug exists and one person has found it, so can another.  This
        means that even though you may keep a bug private, somone else could
        find it and start to exploit it.  By keeping the bug private, you are
        placing me at risk, because I don't have knowledge of the bug.  That's
        iritating.

2.      You have gone open source.  You are going to lose the advantages of
        open source, if you start hiding bugs from everyone.  Bugs getted fixed
        faster the more knowledge there is about them because it provides
motivation
        to developers.

3.      The Netscape-confidential sounds to me like the classic case of
security through
        obscurity.  It doesn't work.  It's bad.  We all know it.  Don't do it.
        Every good security analyst and crypto expert will tell you that
security through
        obscurity is no security at all.  Someone else will find the bug.
Admittedly,
        its nice to be able to go to your boss and say we have found a security
bug,
        but don't worry, we have already fixed it.  Problem is that you have
now placed
        your customers in a higher state of risk, because the customer has no
knowledge of
        the bug, and thus can't provide advisories internally, and the bug
probably won't
        get publicized enough for them to know they need to upgrade.

I respect netscape, and I think that mozilla/navigator/communicator are
great, but I think
obscuring security realated bugs is a mistake.

Matthew M. Copeland
matth...@designlab.ukans.edu

 http://slashdot.org/article.pl?sid=00/03/28/0054248&mode=flat

--
 "This behavior is by design." microsoft on ASP errors
Try a mozilla milestone today! - http://www.mozilla.org

Frank, Dan, Mike: you have exactly the right attitude here. For goodness
sake don't let rabid Slashdot weenies (or even seemingly-more-sensible
arguments) convince you otherwise. :-)

Gerv

Here's a suggestion:

Let us assume that there is a bugzilla category called Mozilla-confidential
which restricts visibility of the bug to the Mozilla Security group.

Let the reporter of each security bug in bugzilla exercise the right to
make the bug Mozilla-confidential. If the reporter happens to be a "free
spirit", he/she may choose not to do this and make the bug public. But then
then he/she already has the ability to that in a different forum; so it
doesn't matter.

If the bug reporter happens to be a corporate employee and happens to find
the bug on corporate time, then the corporation may instruct the employee
to always make security bugs Mozilla-confidential. So be it.

This way each individual bug reporter, and not some netscape or mozilla
employee, gets to decide whether he/she is happy with the whole
Mozilla-confidential category.

Saravanan

PS As suggested earlier, reporters should always be able view their own
bugs.

Well, I should say here that some of the arguments presented on Slashdot
are in fact not bogus at all, and deserve a serious response. I'll try
to give my personal response to those arguments below, and illustrate
what I think the real debatable issues are and what possible approaches
we have to addressing them. (I apologize in advance for the length of
this as well as meandering somewhat in the course of making my points.)

First, to clear away some of the misconceptions that found their way
onto Slashdot:

To my mind the true debate here is not about whether AOL/Netscape should
keep Mozilla-related security bugs to itself. Mozilla is an open source
project, and Bugzilla is a resource for that project as a whole, not
just for AOL/Netscape. If the Bugzilla database is going to contain
information that is not available to everyone in the Mozilla project
then the justifications for imposing such restrictions have to be pretty
compelling.

Security-related bugs are a case where I believe you can't justify
restricting Mozilla bug information to a single vendor (whether
AOL/Netscape or whoever). For example, another company basing their own
products on Mozilla has just as much claim as AOL/Netscape to have
access to Mozilla security bug information in order to protect and
provide for their own customers. A similar argument would apply in the
case of developers creating their own version of Mozilla for
distribution -- for example, if the MathML developers were to create and
distribute a custom version of Mozilla to the mathematical community.

So I don't think the real argument is about restricting access to
security bugs only to AOL/Netscape. I think the debate is rather about
a) whether security bugs in Bugzilla should be fully public or
restricted to some smaller group; and b) if restricted to a smaller
group, how that group should be chosen. (Or to put it another and I
think a better way, how could any particular individual get themselves
admitted to that smaller group?)

I also think some people are misinterpreting Bruce Schneier's remarks at

http://www.counterpane.com/crypto-gram-0002.html#PublicizingVulnerabi...

as being in favor of full disclosure under any circumstances. Schneier
writes "In general, I am in favor of the full-disclosure movement", but
then later goes on to write "I believe in giving the vendor advance
notice" to allow them some reasonable amount of time to fix the problem.
(Schneier's idea of "reasonable" appears to be more than a week but at
most a month.) So IMO Schneier can't be represented as advocating for an
absolute requirement that vendors fully and publicly disclose security
bugs as soon as they receive reports of them; otherwise what would be
the point of giving the vendor advance notice?

Schneier is in effect saying that the vendor of the software is in a
special position relative to anyone else, and is justified to some
degree in concealing information about security-related bugs until they
can be fixed. It's not a justification that allows concealing security
bugs forever, but it does allow concealing them for some reasonable
period.

Now, the problem with applying Schneier's argument in this case (and
here we're getting into what I think are the real issues) is that in the
Mozilla project we're not dealing with proprietary software supplied by
an single identifiable vendor; we're talking about an open source
project where in effect anyone and everyone can potentially be a Mozilla
"vendor": In the proprietary world vendors are special because a) only
they can fix bugs and b) only they are (ultimately) responsible for
supporting users of their software. In the open source world anyone can
potentially fix bugs, and anyone can distribute versions of the software
to end users. So either there is no "vendor" in Schneier's sense, or
anyone can be a "vendor"; in either case it's hard to see how Schneier's
ideas of "giving the vendor advance notice" would apply.

The discussion in the previous paragraph leads directly to two different
arguments for full disclosure of security bugs, arguments that IMO are
reasonable and deserve to be addressed.

The first argument goes somewhat like the following: given that a)
anyone can (potentially) fix security bugs in an open source project
like Mozilla, and b) we collectively have an obligation to maximize the
chances that security bugs will be fixed, therefore we have an
obligation to immediately and fully disclose information on security
bugs to as many people as possible, because only in that way can we
maximize the probability that the problems will be fixed.

I don't accept that particular argument in the general case, because it
doesn't take into account the fact that with security bugs there are
real risks and that disclosing details of bugs can potentially increase
that risks. These risks go beyond just not having the software work, or
even suffering from simple denial of service attacks, for example by
malicious people putting up web sites that are designed to crash
Mozilla; with major security bugs you have a risk that users' personal
data will be compromised and altered, and that their systems are
subverted for malicious purposes (e.g., through trojans).

If you expose details of such security bugs to more people you increase
the probability that they will be fixed but you also increase the
probability that they will be exploited by people previously unaware of
the bugs. (And here I should say that I don't accept as a general truth
the statement that everyone who can and will exploit a bug already knows
about it by the time it's reported to the developers.) IMO those risks
(of the bugs being exploited vs. not being fixed) need to be balanced; I
can't say exactly what the balance point is, but I believe it's
reasonable to assume that there's some point in disclosure (below
disclosing to everyone) beyond which you could significantly increase
the risk of exploitation without significantly increasing the chance
that the bug will be fixed.

Of course, we don't know what that point is exactly. We can't say for
certain, for example, that there is a group of exactly 10, or 20, or 100
Mozilla developers that is the optimum audience for Mozilla security bug
information, because no one else outside that group is likely to fix
those bugs. But IMO we still have an obligation to maximise the chances
that bugs will be fixed. So if we accept the idea of limiting access to
security bug information, then IMO we also have an obligation to a)
ensure that people who have the ability to fix Mozilla security bugs are
able to join the group without undue hassle and b) put some sort of
reasonable time limit on how long security bug information is not
publicly disclosed. These two policies help ensure that the initial
group includes the people most likely able to fix the bug, and that the
bug will likely be fixed in any event even if the initial group is
unable to do so.

The second argument for full disclosure goes as follows: There are
sysadmins and other people who are responsible for a user community that
would be using Mozilla, and who have the means, the knowledge, and the
motivation to help fix Mozilla security problems. Don't they have a
reasonable claim to be able to view information on reported Mozilla
security problems, arising from the responsibility that they owe to
their users, and that we owe to them as representatives of those users?

I think the answer has to be, yes, they do have some claim to view those
security bug reports. If you accept that argument, then one can go on to
make the subsequent argument that since anyone in the world could
potentially be in the position of having some reasonable claim on seeing
Mozilla security bug reports, then the only justifiable policy is to
make the bug reports fully public as soon as they are received into
Bugzilla.

Again, I don't believe that this argument for full disclosure is fully
convincing. I believe the population of sysadmins supporting Mozilla,
distributors of Mozilla-based products, and other people responsible for
Mozilla users is a proper subset of the total Mozilla user population,
and you can make a case for limiting information on security bugs to
that subset. Of course, as with the case of people who can fix security
bugs, we have no foolproof way of determining exactly who should be in
that group or not. Since we still IMO have an obligation to sysadmins,
Mozilla distributors, etc., we should take the same approach as we
should for developers: provide some reasonable way for motivated people
to become part of the "inner" group allowed to see security bug reports,
and set some reasonable time limits on how long information is
restricted to the group.

A final argument for less than full disclosure of security bug reports
is that given by Dan Veditz: that mandating full and immediate
disclosure for security bug reports placed into Bugzilla is likely to
encourage Mozilla vendors (including AOL/Netscape, but also potentially
others) to bypass the Bugzilla mechanisms in handling security-related
bugs and to handle that information internally and not make it available
to other interested parties in the Mozilla project.

I believe that it's in everyone's interest that Bugzilla be used as a
common repository for bug information by all parties involved with
Mozilla development. I also believe that when deciding on a policy you
have to consider the likely consequences of adopting it. Even though
mandating absolute full disclosure of security bugs can be justified by
arguments I myself can potentially accept (e.g., by the arguments I've
given above), I believe that the consequences of trying to force full
disclosure are in practice likely to lead to a situation where in
practice ...

read more »

One of my motivations here is to avoid having mozilla.org be, or appear
as, a recalcitrant vendor.

I wish someone _would_ post here with Netscape's position, because
otherwise we're just waist-deep in conjecture.  Of course, Netscape and
the other vendors might be perfectly content to let you and I decide the
policy, so they're going to keep quiet.  Dare to dream.

I think I need to make a new post with a more concrete proposal, because
we're getting lost in the sparring. =)

Well, if Netscape is willing to paint mozilla.org with the
Sun-past-behaviour brush, we're doomed anyway.

Providing special consideration to Netscape unnecessarily lengthens that
period, I think, but that's another discussion entirely, and not one
that's appropriate for .security.

I guess.  My concern is that I don't necessarily believe that someone
should have to give up their real identity to be a part of that
notification group.  Lots of proven security folks (Solar Designer,
*Hobbit*, etc.) do their business under pseudonyms, and I wouldn't want
to exclude them out of hand.

And if you're the IS manager for Microsoft, or you work on Opera, maybe
you don't want to reveal that fact, but you could probably contribute
significantly.

(I have these concerns about CVS access as well, FWIW.)

Do you have any experience with people infiltrating
developer-notification lists for malicious purposes?  We've got enough
real problems to deal with here, let's not borrow trouble. =)

Yeah, you should file a bug about that. =)

Mike

--
352041.11 234463.58

- Create secur...@mozilla.org, with the initial members being myself,
Norris and Brendan.  People can be added to that list by approval of the
existing list members.  This group is basically responsible for
determining that something is, in fact, a security bug, and getting in
contact with the appropriate people to find a fix (module owners,
etc.).  They're probably also the people who determine how to describe
the severity of the bug, etc.

It is _not_ my intent that the secur...@mozilla.org group be populated
with reps from all the vendors, because then we have to decide what
constitutes a ``vendor'', and why those characteristics make the group
special, and nobody has the time.

- Create a ``Security Sensitive'' bugzilla group, into which anyone can
move bugs.  Those bugs are visible only to the reporter, the security
group, and those added to the cc: lines. (This will permit the security
group, the reporter, and the pertinent developers to discuss things
within the bug.)

Once a security bug is reported, mozilla.org should immediately post a
workaround if one can be determined, and if such posting does not give
excessive detail about the vulnerability in question.  ``Make the
following change to your security policy for untrusted sites'' would be
a good workaround to post, while ``do not open messages with more than
255 attachments'' might not.

At the same time, a message should be sent to mozilla-security and
mozilla-security-announce, stating that a vulnerability has been found,
the approximate severity of the vulnerability, platforms affected, and
how long we expect it to take to find and commit a fix.  This will allow
vendors and other interested parties to make decisions about release
delays and prepare for redeployment of the appropriate components.

Example:

``mozilla.org has been made aware of a security vulnerability in the
Mozilla software, which affects the 5.0 and 5.5 source trees, on all
platforms.  This is a critical vulnerability, and may allow an attacker
to execute arbitrary code on the user's computer.  mozilla.org expects
to have a fix for this available by April 2nd.  Users should add the
following line to the end of their policy.js file to protect themselves
until the fix is available:
   policy("default", "security.event.cross_domain", "false");
''

Once a fix is found and committed, a followup message should be posted,
giving the details of the fix, and how to verify that the vulnerability
is repaired.  Ideally, mozilla.org should provide .xpis or something to
allow users to upgrade easily at the same time.  This is also the point
where the bug is marked public again, likely.

Vendors who are concerned about the amount of time it takes to spin and
test their own versions should probably consider staying very close to
the Mozilla tree, so that you can just use the Mozilla-provided .xpi
files until your custom versions are ready, similar to how Microsoft
often releases initial patches very quickly, with a caveat that they
were not exhaustively tested, and then will update them if QA finds
anything disasterous.  In the presence of a workaround, that seems
sufficient.

Mike

--
353506.39 235854.74

OK, so the question then becomes: How do we maximize the chances of
getting people involved who can actually fix the bug? For example, if
someone has expertise in fixing security bugs, how can they put
themselves in a position where their talents will be applied to this?
Presumably your answer is that they win the trust of the modules owners
and other parties consulted by the core secur...@mozilla.org group, in
the same manner that anyone else becomes trusted to be involved with
active Mozilla development.

Understood. You're in essence proposing an informal mechanism to
accomplish the same goal (of widening participation), since developers
at a given vendor could certainly work to put themselves in a position
where they were copied on security problems based on their perceived
ability to help with them.

To respond to the comment from R. Saravanan, certainly it's the
reporter's option to not classify a particular bug as security
sensitive, or to disclose it publicly through other forums. However by
allowing anyone to move a bug into the security sensitive category,
there's the potential to cause disagreements about previously reported
bugs "disappearing" from public scrutiny.

Also, did you really mean "anyone" here, as in "anyone with a Bugzilla
login" could classify bugs as security sensitive? Or are you proposing
some other criteria?

By mozilla-security I presume you mean the existing mailing list
bidirectionally gatewayed to the netscape.public.mozilla.security
newsgroup. I also presume that you're proposing creation of a new
mozilla-security-announce mailing list, since I don't believe one
currently exists. Would this mailing list also be gatewayed to a
newsgroup, e.g., netscape.public.mozilla.security.announce?

I'm a little unclear about this. Are you proposing that "vendors"
(however defined) don't get advance notice of the fix itself, unless
they're actually involved in fixing the problem and are thus copied on
the bug from the start? I understand your reasoning here and below, but
I suspect that major "vendors" will lobby very hard to get some sort of
head start. (Of course, this goes back to the point I made above about
their developers putting themselves in a position to be involved.)

That's all my comments for now. In general I think it's a reasonable
proposal, but I'd like to hear others' opinions before making up my mind
once and for all.

Frank
--
Frank Hecker            work: http://www.collab.net/
fr...@collab.net        home: http://www.hecker.org/

To prevent misunderstanding I should clarify what I mean by the phrase
"trusted to be involved with active Mozilla development". I mean trusted
enough to have their patches accepted into the core Mozilla source tree,
or to be given check-in access to that source tree. (Of course anyone
can do Mozilla development on their own private tree without asking
anyone for permission.) Just as there's a trust-based "barrier to entry"
to someone getting patches accepted or obtaining check-in access, in
your proposal there would be a comparable barrier to entry to getting
included in on discussions of security-related bugs.

Frank
--
Frank Hecker            work: http://www.collab.net/
fr...@collab.net        home: http://www.hecker.org/

I think only the reporter, individual or institutional, should have the right
to classify the bug as being security-sensitive.  If the security group
thinks a bug shouldn't be public, they have to make a case for it and request
the reporter to re-classify it. I think this will work in most of the cases.
If the reporter is obstinate and refuses, then he would precisely be the kind
of person who would be willing to use a different forum to air his
complaints. I think it would be better to have all this "dirty linen" washed
in the bugzilla forum than in a different forum.

Saravanan

This sounds good to me for the most part. Thanks for thinking about the
issues and posting this proposal.

It sounds like a lot of work to do the notification of the bugs. Would
it be acceptable to you to (a) wait until, say, M16, before beginning
the notification process, and (b) then only do notification for more
serious problems? My concern here is that during development I'm still
dealing with a lot of security bugs and all the extra reporting
requirements would only slow me down in fixing them. Once we have more
users then the reporting requirements become more important.

--Norris

Eggs-actly.

Mike

--
381597.37 258992.02

If you can give a meaningful definition of "vendor" for the Mozilla
context, we could discuss some sort of advanced notification.

Mike

--
381609.43 259002.70

We should also be sure that the proposal applies to security bugs and not general to
general contributor confidential information.  We want to encourage security bugs to
be handled through bugzilla.  Confidential information of a contributor is
different; we want this data to migrate away from bugzilla into other repositories.

Mitchell

Arguably, until there's a .0 release, we don't have to be as circumspect
about the privacy and notification process.  (At least, I'd be willing
to make that argument.)

Users of development or pre-release builds are assuming a variety of
system-damage and security risks -- for a long time we didn't have any
capabilities at all! -- and I think that's a good way to be able to go
faster during development.

The general open-source practice seems to be:
 - some sort of fix-then-notify process, similar to the one I've
proposed, for release/production versions, and
 - no such process for development/alpha/beta/pre-release versions,
because, as you mention, it's too expensive to track all bugs with
security ramifications during development.

If we decide that we want to notify for pre-Mozilla-5.0 releases[*],
then I'm willing to take some of that notification burden on; much of it
will be boilerplate.

[*] If it turns out that a vendor/downstream-consumer wants to start
being quieter about security bugs before the Mozilla 5.0 ``release'',
perhaps because they ship a .0 of their own based on pre-.0 Mozilla
code, then that should be entertained, but the vendor in question should
be ready to take on the burden of that process.

I had thought that you wanted to keep security bugs quiet already, but
if it turns out that you don't, then I'm happy to delay throwing the
security-notification switch until there's a .0 Mozilla release, or
someone steps up and asks for it to be thrown.

I would think that the ``secrecy'' and ``reporting'' requirements stem
from the same root cause, the need to protect users from malicious
attackers, and would therefore scale at approximately the same rate.  Do
you disagree?

Mike

--
381632.67 259023.78

I believe you need to also include the assignee and QA contact.