221538 - Consider a policy for security bugs such that people scanning bonsai/cvs commit history can't immediately detect security bugs and work to build exploits

Status: RESOLVED WONTFIX

(mozilla.org :: Governance, task)

Description

[:glob ✱]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031001 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031001 Firebird/0.7+

i don't know if this is possible, but ..

i browse bonsai for interesting checkins every now and then.  while i may not be
able to view a bugzilla bug that i don't have access to, i can still view the
checkins associated to that bug.  this effectivly bypasses bugzilla's security.

for example, this bug was recently checked in

10/07/2003 16:02	brendan%mozilla.org 	mozilla/ js/ src/ jsscript.c 	3.48 	15/7
 	Late-breaking security fix (221526, r=shaver). 

i don't have access to bug 221526

however i do have access to

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/js/src&command=DIFF_FRAMESET&file=jsscript.c&rev1=3.47&rev2=3.48&root=/cvsroot

so it appears that bug is about "Script.thaw [having] a hole wide enough that
you could hack your own native function and call it".



Reproducible: Always

Steps to Reproduce:

Comment 1

[Dave Miller [:justdave]]

There's not really any easy way for Bonsai to tell whether a bug is confidential
or not currently, nor does bonsai have any concept of who you are when you're
looking at it.  Although those might be good feature suggestions for future
additions to Bonsai, at the moment this is a developer education issue (i.e. be
careful what you put in your checkin comments if the bug is confidential and
can't be opened yet).  I'm not sure what Mozilla's policy on such issues is, but
what we've been doing for Bugzilla is holding off until we're ready to release
before we check in patches from security bugs, precisely for that reason, so it
doesn't show up in Bonsai before we're ready to reveal it anyway.

Comment 2

[timeless]

I'm double confidentializing this bug. don't remove the blocks until
brendan and people from security approve.

there's nothing we can do in an open system to prevent people from
finding out about security fixes. please don't abuse the fact that
cvs is an open system.

people can of course just as easily watch cvs update to find out
about changes. brendan would have had to have come up w/ a more
creative way of masking this feature. he could have said he was
removing this feature because no one used it instead.
however because brendan committed this fix to various branches and
the bug referenced was confidential people can put two and two
together. 

Now, security group could establish a policy of masking security bugs
by filing public bugs with obfuscated logic explaining changes
which happen to have the result of fixing the security problems
relating to bugs, but i doubt people would be interested in doing it.

Comment 3

[Dave Miller [:justdave]]

As an added note, if you can get the diff from bonsai, you can get it from cvs
on the command line as well.  So securing the diffs would have a negligible effect.

Comment 4

[:glob ✱]

i think you should at least aim for hiding the checkin from the casual user (ie
someone without command line cvs knowledge).

how about changing bonsai:cvsquery.cgi so that it hides any checkin with a
keyword in the description?

eg. "Late-breaking security fix (221526, r=shaver). [hide]"


.. although that will affect people with access to that bug and who use bonsai.

Comment 5

[Daniel Veditz [:dveditz]]

Why is this bug confidential? While we do--reluctantly--hide bugs when we feel
the public risk is greater than the benefits of openness I don't see how this
bug falls into that category. Any mechanism we come up with, if one is even
possible, would need to work whether or not people knew about it because the
people we need to protect against manage to figure these things out if they're
motivated enough.

Comment 6

[timeless]

at the time of the bug filing, the bug it referenced was not confidential...

Comment 7

[Daniel Veditz [:dveditz]]

Oh, right -- because it contains information about bug 221526. That's public
now, this can be open, too.

Comment 8

[Reed Loden [:reed]]

--> Governance

Comment 9

[Jesse Ruderman]

Even without checkin comments, people would be able to get a list of checkins corresponding to hidden bugs with little trouble and look at the associated code changes.  I think the only way to get around that is to keep fixes for non-public security holes out of public cvs (and out of public tinderbox builds, for reverse-engineering and license reasons) until we're ready to issue a security-fix release.  I think we should consider do that, even though it would require extra effort and would exclude most of the community from QAing security patches.

Comment 10

[Benjamin Smedberg]

I am not sure that such an approach is practical given the limitations of CVS. It is much more practical if we were able to switch to one of the distributed source control systems (git/monotone), where we could keep real "private branches" on alternate machines and the SCM system has generic branch-import mechanisms.

Comment 11

[Reed Loden [:reed]]

zak: Please only change the assignee and not the QAContact when you are taking a bug. Many of us watch the QAContact for changes with Governance bugs, and by changing it, it causes bugmail to be lost and never seen. Thanks!

Comment 12

[Zak Greant]

Our current licensing model and development model doesn't allow for the development of private branches with public testing.

This is just a side effect of the way that we work.

Closing the bug for now. Feel free to reopen with concrete suggestions for resolution.