Slashdot Mirror
Netscape Nondisclosing Mozilla Security Bugs?
AP writes: "Mozilla developers are contemplating disclosing Mozilla security bugs only to a limited group of people, unavailable to the public until a fix is found, as indicated in this news post and the discussion thread. Are Mozilla developers missing the point of open source (implying open security bugs) or are they under pressure from Netscape? Tell Mozilla developers what you think." Please read this post from MozillaZine, in which it is explained that there is mere open /discussion/ about security and disclosure in the mozilla security newsgroup. Thanks to Hard_Code for the hook-up.
It was the February issue that discussed this. I agree with you and him, and I think Netscape could avoid this whole row by promising a fixed "sunset" after which bugs will be publicized no matter what. A month should do it - most security problems that can be fixed with patches at all seem to be "d'oh!"s that get fixed very rapidly after identification.
I would recommend that all open source projects do the same. If you spot a security bug in the Linux kernel, or Apache, or sendmail or whatever, let the maintainers know quietly and give them a chance to announce and fix in good order; tell the world only if this procedure doesn't seem to work.
--
Xenu loves you!
This is an outrage. It goes completely and totally against the principles under which Mozilla is being developed. While I can see where the idea comes from, it's the same shortsighted lunacy which affects most proprietary vendors today.
It is precisely because security holes in Linux are announced openly that it is so secure. There will always be security holes in software, so the race for most secure will go to the one with the fastest bugfix turnaround time. That will go to the one with the most eyes looking at the code. And that means the one which doesn't try to "hide" its flaws.
This does pose a potential problem, however, because you are dealing with Web browser users here. Most aren't savvy enough to upgrade the browser every time a new hole is found and patched. This is why Mozilla's modularity needs to be carried one step further, such that security updates can be found and fixed at the touch of a button. I envision something like this: an "Update" button on the toolbar. This button is normally inactive, but when some central repository (Mozilla.org perhaps?) finds and posts a bug, the button activates and glows (or undergoes some sort of obvious state change to alert the user that something is wrong). This button will take the user to the security site (wherever that might be), where the user is given an explanation of the bug, and the chance to automatically download and install the fix. This last process has to be made as transparent as possible; remember we're dealing with everyone from techno-gods to people who wonder why the cupholder on the front of their PC isn't working anymore after they set the huge drink on it.
But the fact is, security through obscurity for an open-source project is hypocrisy of a very high order. I seriously hope Mozilla doesn't take this path. The results would be disastrous for Mozilla and Open-Source in general (M$ in particular will jump on this as a precedent: "see, even Open-Source guys know openness doesn't work!")
1. PGP has never relied on obscurity.
2. "When it comes to things like my medical records, or bank statements, then I think I'd like them kept obscure"
I'd rather have mine kept secure. You seem to be mixing the two. Obscuring your records by XORing them and posting them to USENET probably won't give you the desired result.
3. NSA also doesn't give KG-84's, KY-71's or whatever they're using this year out to anyone who wants one, that gives them a decisive edge in this case (though I've always wondered why the physical boxes themselves were always security-rated lower than the information flowing through them.)
This story has a lot to do with security through obscurity, since "normal" bugs don't get this treatment, just security bugs.
Maybe you should re-evaluate the meaning of the term "security through obscurity", as you seem to be missing it.
Paul
http://www.pauldrobertson.com
Many consider it bad form to post to BUGTRAQ without first giving a software vendor a chance to address the problem.
It's also considered bad form for a vendor to sit on a security bug instead of dealing with it promptly.
Up to this point, Mozilla has actually been somewhat unique in that, not only does the public have full access to the current source code, it also has access to all bug reports. While this is a commendably open attitude, it's not the best way to protect the end user.
All this policy change really means is that, in the short time between when the bug is first reported and when a fix is issued (or it shows up on BUGTRAQ without a fix), it's not posted in BugZilla for all the world to see. Effectively, what this means is that there are going to be fewer people out there trying to write exploits based on the bug report. This is no different from the policy in use by any other team I've ever encountered.
If they publish information about the security bug while their product is still vulnerable, what do they gain? It will cause the userbase to worry more. Some may stop using the product until the fix is available, but what about those who don't have that option? What if you've deployed Mozilla in 30 public labs on campus, on 5 different platforms, you're the only one who can do anything about it, you have to be on campus to fix it, and you're reading about the problem while on vacation in Cancún?
The above scenario is extreme, but not atypical. For most end users, the only real difference will be that it's suddenly become much more likely that someone will brew up an exploit for the security hole.
So there's a security hole in the browser. So what? Do you really think the software you use is secure? There are a *lot* of free software programmers out there who write the kind of code which would spell "instant root shell" if it was ever run suid root. Even if none of the programmers working on Mozilla are like this, there are still a lot of things that can go wrong just because of the sheer complexity of the application.
If you think the programs you're using are secure, you're kidding yourself. The most security-conscious development team I've ever had the pleasure of observing is the Samba team, and even they've had a security hole or two over the past few years. There are always going to be problems, and if they're security problems, I'd much prefer that only the program maintainers know about it, instead of publishing it for all the crackers of the world to see.
I for one commend the Mozilla team for keeping the user's best interest in mind with this decision.
If you don't like the plans that mozilla.org and it's contributers come up with for handling certain security issues there are a couple of things you can do about it. You can grab the Bugzilla code (or some similar open source tool) and set up your own system. If you build something with enough value over the current BugZilla maybe people will start using it and you can admin it and set the rules about how to mark certain bugs in certain ways. The Mozilla community has been holding very public discussions about how to deal with bug reports, from issues like security bugs to issues like what to do with personal ads that find there way into Bugzilla. Most of these discussions are still ongoing. If you contribute to Mozilla (in any way) then I think your input to these discussions is valuable. I participate. I voice my opinions. Bugzilla and Mozilla are the way they are in part because I participated in the process.
/. The place to make Mozilla better is Mozilla. This project is being developed by people who care about making something great. Even the people getting paid to work on it care. Tough decisions are made every day and they are made in a fishbowl world. If you don't like what Mozilla is then fix it.
If you're unhappy with the direction Mozilla is going on any issue the place to make it better is not on
Asa
(posted with a damn nice Mozilla nightly build 032708)
At http://www.zdnet.co.uk/news/2000/ 12/ns-14378.html Paul.
You are lost in a twisty maze of little standards, all different.
Man, people...the first thing I do when I see a suspicious story is go to the SOURCE.
/discussion about/ security and disclosure:
e =1268
On MozillaZine.org they have a post explaining that there is only open
http://www.mozillazine.org/talkback.html?articl
It's 10 PM. Do you know if you're un-American?
We can debate the morality of nondisclosure ad nauseum. I'm more interested in engineering than morality --- and the fact of the matter is that policies that discourage full and open disclosure DO NOT WORK. They hinder the discovery of important security flaws and create an environment in which black hats have a significant advantage over white hats. Remember, the black hats don't give a damn about Mozilla's disclosure policies, and history tells us that they tend to find the problems first.
Nondisclosure has (dubious) practical benefits for tightly-guarded closed projects. Mozilla obviously doesn't qualify, and the idea that security flaws in Mozilla's open codebase can be meaningfully hidden is ludicrous.
As this is a Slashdot story, I don't trust the veracity of the claims that Mozilla is going to try to hide security information. However, if, contrary to the established best practices in the security community, they decide to go ahead with some sort of Mozilla "inner circle", they are going to give a nice black eye to Open Source's security argument.
note: this is not stricly related to this post, it (unfortunately) may apply to many other appeared on /.
/. generals.
Are Mozilla developers missing the point of open source (implying open security bugs) or are they under pressure from Netscape? Tell Mozilla developers what you think.
OK, so why do we al have to think the same? The country where I came from had a bitter fight for DEMOCRACY, which means, we don't have to all think, speak and act alike. Freedom of thought, freedom of expression etc. So, please, don't imply we will all tell Netscape that they don't get it, because, shock horror, we are not an army that is under the command of the
sorry if this is offtopic, I think it had to be said, sooner or later.
Sigged!
Surely all they are doing is witholding info on the bugs, not the actual source code, preventing people from taking advantage of the weakness until it's fixed. The code is there, go find the bugs & weaknesses yourself!
On the other hand if the script kiddies already have an exploit for a hole then not telling sysadmins about the problem is obviously counterproductive.
So, limit it to 48 hours, and only apply the embargo if the knowledge is not already available in the cracker community.
Paul.
You are lost in a twisty maze of little standards, all different.
I think this is behaving in a responsible way towards users of the software. The Apache group work in a similar fashion; from the Apache website:
o de@apache.org. We cannot accept regular bug reports or other queries at this address, we ask that you use our bug reporting page for those. All mail sent to this address that does not relate to security issues will be ignored.
Reporting Security Problems with Apache
The Apache Group takes a very active stance in eliminating security problems and denial of service attacks against the Apache web server. We strongly encourage folks to report such problems to our private security mailing list first, before disclosing them in a public forum. The mailing address is: I-found-a-security-problem-in-the-apache-source-c
Note that all networked servers are subject to denial of service attacks, and we cannot promise magic workarounds to generic problems (such as a client streaming lots of data to your server, or re-requesting the same URL repeatedly). In general our philosophy is to avoid any attacks which can cause the server to consume resources in a non-linear relationship to the size of inputs.
stty erase ^H
Anyway, this isn't anything to get upset about. If you actually bothered to read Bugtraq, you'd see that this is pretty standard practice.
Most of the time, when an exploitable bug is found, the vendor is contacted first and is given some time to come up with a fix. Sometimes a workaround is posted along with the exploit.
Bottom line : making the world aware of a problem there isn't a fix for is usually bad policy. Don't give me that 'we have a right to know' crap. If you want to know, go and find the bugs yourself. Because otherwise, if you know so do a million script kiddies. And telling people not to use Netscape whilst a fix is being worked on is hardly doable.
*borkborkbork*
Look, the point of open source software is that it is analagous to the scientific concept of "peer review". You'll notice that there is no scientific concept of "review by every lugnut who knows ftp". That's because scientists aren't prey to these libertarian/egalitarian visions in which "everyone can contribute". The fact is that the marginal contribution beyond the first hundred or so developers is pretty negligible.
You have to think in terms of marginal benefit versus marginal cost. The Mozilla developers may not be super l33to sk33to, but they're at least competent to work on Mozilla. The various long-haired lugnuts, slashbots and script kiddies who will be filling up this thread with karma-whoring sermons on "give us the source!" are massively unlikely to add anything to the exercise but noise.
This is the way forward. Open source, but peer review only during development. With a defined way to get into the "peer group". Thus shutting out the whiners and lamers, and not letting the whole product be compromised by someone's exploitation of a bug that they had no business seeing.
What if someone found a hole in Apache? Should they post it far and wide, or should they quitely pass it along to the main developers so that the hole can be closed before half the world's websites are replaced by "ThiZ Site HAXed by KeWl d00d"?
It should be openly published. Nobody can know for sure that they are the first to discover the bug. It could've been circulating in hidden circles for years - without anybody knowing.
It is blatantly disrespectful to the customers not to open the bugs to the community. Only that way they may secure themselves.
--
Rune Kristian Viken
--
"Rune Kristian Viken" - arcade@kvine-nospam.sdal.com - arcade@efnet
"Rune Kristian Viken" - http://www.nwo.no - arca
*sighs* OK, here we go again.
1) Not disclosing a security hole does NOT make it go away.
2) Software developers don't always know all the security holes being actively exploited. It is entirely possible that the hole we're being 'protected' from is in fact being exploited in the wild, and the only thing that's accomplished is we're not being careful in our use of the product until it can be patched.
3) Non-disclosure tends to slow the repair of security holes in any environment, never mind open source, where your very strength is in your userbase.
I personally would be in favor of draconian disclosure. When a security bug is discovered, pop up a dialog box, forcing me to read about the advisory and 'continue at own risk' until a fix can be developed and a notice of said fix distributed using the same draconian alert box.
That way everyone who uses the product (rather then just those of us who read full disclosure lists like Bugtraq) knows what exactly is going on and can change their habits accordingly. Additionally you'll have every open source programmer on the planet competing to squash the bug.
Seems like a no brainer to me people.
---
Remove the rocks from my head to send email.
----
Remove the rocks from my head to send email
On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before
Everyone is whining about "security through obscurity". Well, sorry, the other forms of security are already gone -- that's what it means that there's a security bug. Security through obscurity is better than nothing.
Unlike closed source projects, even a general description of the problem might be enough to find the exact bug, and to develop an exploit for an open source project. This means that it's even more critical that the nature of the bug isn't leaked until a solution or work-around is known.
What if someone found a hole in Apache? Should they post it far and wide, or should they quitely pass it along to the main developers so that the hole can be closed before half the world's websites are replaced by "ThiZ Site HAXed by KeWl d00d"?
Bruce Schneier addressed this in a recent cryptogram. See: http://www.counterpane.com/crypto- gram-0001.html
Of course, there is the possibility of Netscape taking the microsoft approach -- just ignore it until actual damage is caused -- but I think this is unlikely. They are already agreeing that the bugs need to have a distribution other than netscape only. I think it's pretty unlikely they would let security bugs be swept under the rug.
--Kevin
Mozilla is still under development and should not be treated as a release product. Security bugs should be published openly to ensure the fastest and most robust fix possible. There is no sense in concealing information about a product still under development. z