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.
I take it we'll be getting your crack of PGP any day soon, then? How about the non-open protocols used by the interbank system? Or perhaps you're working on those military cyphers? The NSA has a few coding machines which are kept under armed guard 24 hours a day! That's so obscure that it's bound to be incredibly weak
"Security through obscurity does not work" is a complete substitute for thought about the relative uses of obscurity and openness. It's just as permissible to say "Security through openness does not work". In fact, security through any single one-word concept is likely to be weak, because security is a whole process.
When it comes to things like my medical records, or bank statements, then I think I'd like them kept obscure, thank you very much. There are other forms of information, like nuclear bomb plans, which I'd also like as obscure as possible, simply to make things difficult enough that people won't bother.
When it comes to software, then yeah, open the source. But there's no need to shout about bugs to people who have no intention of helping to fix them. The source of Mozilla is open, so if you spot a bug yourself, put it on your website, post it to slashdot, do whatever you like.
But when the Mozilla developers spot a bug, why the hell should they not keep it to themselves? The bug is found, so it's not a question of "more eyes". They're already working on it, and it's pretty unlikely that anyone outside the project is going to have a far superior solution. How in hell does it help security for them to give the cracker kiddies their raw material?
This story has nothing to do with "security through obscurity". The source of Mozilla remains open. It's just a group of people exercising their right to work together and not to invite outside interference.
And people who first-post stupid slogans for the appreciation of the slashbot moderators should be ashamed of themselves.
Check it out at mozillaZine.
I'm willing to bet that the average end-user of Mozilla (consumer) will not actively check for updates, patches, security fixes etc (assuming that distributions such as Netscape will have the same kind of wide-spread usage that Netscape 3 enjoyed). So will Mozilla (or Mozilla distributions) check for updates - perhaps in a way similar to IE and Windows98? Otherwise your average consumer will be running an older version of the browser whose security bugs could potentially be all over the internet for every little script kiddie to exploit.
Windows update is nice, but it only alerts the user after the fix is known, not when the bug is reported.
--
"L'IT c'est moi!"
Because "the community" includes thousands of script kiddies. I think limited initial disclosure is easily justifiable.
I'm apparently to look out for other such cases of error, but some at Netscape don't think that I should be able to view Netscape-confidential bugs, so that might get tricky.
We Shall See.
Thank you sir, for pointing out the obvious point everyone seemed to be missing.
It seems the great Netscape/AOL group in their corporate wisdom forgot all the valid reasons why they made the damn product open source and began this project in the first place. It is time for the flood of perfectly flame-free reasonable commentary to everyone in Netscape's corporate ladder. Anyone out there have an email list? They need to be reminded of the reasons why they started this to begin with.
ACK
While in the long term, security through obscurity doesn't work, in the short term, I'd think that it's a workable solution. I wish that the lot of ethical hackers would announce their discovery's of bugs and holes to the company's whose products have them and, depending on the complexitiy of the issue, hold off on making any announcements until a fix is at least available.
I mean, yes, the more skilled crackers will still have a chance to find out and exploit the holes, but it might at least prevent some of the script kiddie utilities from popping up, until at least a fix is available. If people get hit and there is no fix, it's basically terrorism (on a much larger scale). If people want to browse the web, they've got few real choices, so it's not like they can go "oh... IE sucks, i'll switch to netscape. Oh, netscape sucks too, i'll switch to Opera, oh... opera sucks, what do i do now?"
If fixes are available, and people still get "hit" by the script kiddies, at least they have a some one to point their finger at, with that person being themselves.
I agree entirely.
;)
.|` Clouds cross the black moonlight,
Let's take an ancient example: unix fingerd. Bugs, can get root exploits, and all that stuff. But note, NOW FIXED!
You do still get "sysadmins" who think that "just not running a fingerd" is to save on the bugs; but it's really no excuse to deny people a reasonable service (in the tcp sense if not legalistic!) just because "it used to have bugs". *Every* piece of software out there "used to", and every piece of software out there "still might have". So run it if you want and keep it up to date and pass on what you know and implement security fixes....
Oh look. Did I just describe something compatible only with keeping the whole thing open? Oops
~Tim
--
~Tim
--
Rushing on down to the circle of the turn
bah.. what do primarily C++ mozilla programmers know about fixing security flaws? Hands up, how many mozilla developers know how to write a buffer overflow? How many of you know how to find a buffer overflow.. I mean, you coded it in the first place, obviously you don't know what you coded was a bad thing. So yes, if someone on the mozilla team finds a security bug, go ahead and keep it secret.. the "script kiddies" trolling the source for overflows will do the same.
How we know is more important than what we know.
I think there's been ample evidence that this is not the case. Let's look at the IIS bug that came about this last summer. Big buffer overflow in a major server product. Came out in bugtraq among other garden spots. Exploits and fixes hours later.
There are more white hats then there are black hats. We should use our numbers to solve these problems quickly by finding a solution and DISTRIBUTING the information as quickly and as widely as possible.
Doing otherwise will alianate some of your best sources for fixing the problem, your opensource programmers. How long do you think a security bug would remain unpatched given the number of eyes an open source software project like Mozilla has looking for a solution. Frankly I'm sure we'd have a patch before they had an exploit for it, both of us starting from the same place.
Security through obscurity gives a false sense of security to everyone.
Consider the (not totally unrealistic scenario. Not saying this would happen with Netscape/Mozilla but it could and has happened with other software products.) Netscape finds a security bug, and generates an internal bug for it. It gets assigned to an overworked programmer, (and let's face it they're all overworked) who says, "well I have this list of things to do, and this bug isn't crashing computers cuz noone knows about it, so I'll just put it on the back burner". In the meantime, someone else with access to internal bug reports decides to 'leak' it to a friend to prove how hooked in he is. It goes out to the 313t3 crowd, we have an exploit and script kiddies, and eventually the rest of the world finds out through bugtraq. Oops.
Think it's far fetched. Check your bugtraq archive site, there are piles of "I sent this to vendor X, 3 months ago, they haven't done anything about it, so I'm submitting it to Bugtraq now" posts. Happens all the time. If we don't talk about it, we lose the biggest advantage the net gives us. Communications.
Disclaimer: I am not affiliated with bugtraq in any way other then being a loyal reader for many years.
----
Remove the rocks from my head to use my email address
----
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
and only apply the embargo if the knowledge is not already available in the cracker community.
Ah, now there is the crux of the problem. How do you know? Sure it's easy if someone puts a 'sploit on bugtraq. But what if they don't? What if some group keeps it to themselves, abusing the bug in private. Now maybe you argue that 48 hrs isn't that bad. But what if that is 48 hrs where some web site is infecting each computer connecting to it with a worm. We've seen lots of browser bugs that allow files on comptuers to be manipulated, so this isn't way out in fairy tale land. This would be a pretty standard "keep it quiet we don't want anyone to know the emporer isn't wearing any clothes just yet" bug. I am a good internet user. I have a personal firewall between my browser and the net. I have the skills to be able to defend myself if I know I'm being attacked. Do you want to guess how irate I'd be if I found out Netscape/Moz. withheld details of the exploit that compromised my home computer, or worse yet, the company I work for because they wanted to avoid bad press? Ha! Just watch the press, "Open Source software causes Internet Worm, Gates says, 'I told you so'". Seem far fetched? I argue it's simply a matter of time.
The ONLY socially responsible thing for a software organization to do is to publicize it as far and wide as they can as soon as they can. That way they can use that as a defense when the dark smelly stuff hits the oscilating airflow assist device.
----
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
They have missed the point of open source, but there are precedents for doing this, eg a developer notices a way mozilla could leak credit card info. However:
1. By hiding the hole they are blocking interested developers from having a chance to explore and fix the problem
2. In many cases the bug would probably be talked about (and possibly exploited) on Bugtraq anyway
3. They should be secure enough in thier beliefs that if a serious security bug is found instead of hiding the fact, they should issue an announcement saying there is a bug, and leave it up to people to decide if the software should be used until a solution is found. There could be levels of this, eg:
a) Bug is serious, and being exploited in the wild,
b) Bug is serious and not being exploited
c) Bug is minor, but some people may be affected
Once a fix is found this could be distributed on a mailing list.
There are some bugs that are closed to the public. At least four SSL bugs (all dependencies of 13785) are: 28335, 28418, 28430, and 28333.
--
The shareholder is always right.
The article goes on and on about "security through obscurity" vs. "many eyes", but fails to mention a single actual security related bug.
The majority of the software mentioned is actually security software -- firewalls and detect stuff.
The only "exploit" mentioned is the DOS against Yahoo et al a couple weeks back. Which, they again fail to mention, did not exploit bugs in software. Or, it didn't exploit any bugs in the software run by the sites attacked.
It seemed more along the lines of, oh, look at the security companies who gave us money to mention them. See their neat products.
--Kevin
From reading the referenced post, it appears that there will be a system wereby "security" bugs only appear on bugzilla if you are logged in as a member of the security team.
Currently, it is limited to "netscape only", which doesn't make that much sense, because not all of the main contributers are in that category.
--Kevin
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.
This is generally what happens on mailing lists like Bugtraq. However, often it's better to just post to Bugtraq first off and let people confirm/analyze it, then figure out how to fix it (usually easy when you know what's wrong). For instance, over the weekend someone posted something that crashed his Slackware 7 / 2.2.14 machine - he thought it was a kernel bug. I tried it on my RH 6.1 / 2.2.14 machine (who needs uptime?), but nothing happened. So maybe it's a problem with PAM? Maybe something else? Probably it'll be figured out in a few days, and a fix will be applied. But it wasn't a kernel bug: he would have just been bothering the wrong people.
Note this is not the case if you know what the problem is (ie, there is a buffer overflow in line xx in somefile.c in Apache, or whatever). In that case the right thing to do is to let the proper people know, then post to Bugtraq and/or other appropriate mailing list(s) after a week or two has passed and a fix is available.
It's generally considered good etiquette on mailing lists like Bugtraq to give the vendor at least a week advance notice before posting, to give them time to at least start working on a fix. However, if Mozilla is going to take bug reports and "cover them up" for an extended time, I can certainly see people posting exploits without bothering to let Mozilla know: why bother?
In some situations, this method is acceptable (for instance, some security holes in DNS and Kerberos were hidden for years to allow fixes to be implemented). However, Mozilla (however over-hyped it is) will never have the wide spread adoption of DNS or Kerberos - if it's lucky and well managed it may become popular in the *nix/BeOS/MacOS/etc world, but I can't see it going much anywhere on Windows. It's not, and never will be, wide spread enough or important enough to hide security bugs.
Open Source is analogous, but not strictly equivalent to scientific peer review. Among the differing concepts are:
"Given enough eyeballs, all bugs are shallow."
and
One is NOT allowed to propagate alterations to community work without disclosure.
Neither of the above are true in scientific peer review, and both are frequently touted as essential elements of Open Source success.
"You can't get something for nothing." - my grandfather, on the stock market and Reaganomics.
If I'm administering workstations, I may well install Mozilla. As admin, I should be concerned.
Consumers don't care about bugs, and don't like to update their browser every week with a 56K modem.
Generally true, but presumptuous. This is a Microsoft-esque outlook: we know what you care about, and we're providing it for you, like it or not. Besides, by that logic, why not announce the bugs before there are fixes? The end-users probably won't update their browsers anyway.
"The best we can hope for concerning the people at large is that they be properly armed." - Alexander Hamilton
You know, such things have always struck me as potential security holes in themselves. For instance, a man-in-the-middle attack might be possible. I run Debian's apt-get, and I always wonder just a little...
"The best we can hope for concerning the people at large is that they be properly armed." - Alexander Hamilton
I think you make a good point; often we don't talk about freedom, and we should. But nobody's talking about hiding the source. A bunch of people are just deciding under what circumstances they'd like to discuss the source. Since they're not talking about stopping anyone else from doing anything at all, I can't see that anyone's rights are infringed by this.
"The best we can hope for concerning the people at large is that they be properly armed." - Alexander Hamilton
If there's a security hole on my system as a result of my installing Mozilla, and the Mozilla developers know about it, I think they have a certain ethical responsibility to let me know about it. Then I can decide how to deal with it. Because I make the decision, my needs can be taken into account.
The consensus in the free software community seems to be that empowering the user is a good thing in general. On the topic of security in particular, we think that if you empower both sides by letting them know what's going on with the code, it's a net gain for the "white hats".
If we really hold such a belief, perhaps we should have the faith to see it through to its conclusion.
If you don't disclose until there's a fix, I'm stuck with an insecure system, banking on the obscurity of the bug till someone lets me know what's going on. If you disclose right away, I have the choice to take whatever steps I feel appropriate, including suspending use of the program.
IMHO, choice is a good thing here, as elsewhere. But like I said, the other side has some respectable points.
"The best we can hope for concerning the people at large is that they be properly armed." - Alexander Hamilton
Well... okay the bugs may be fixed. But if the Mozilla developers do not put the bugs with the rest (on bugzilla) then they can expect to spend much more time fixing them. And perhaps some will never be fixed...
;)
Aside from that, having the bugs available for everyone to view will allow users to make decisions about whether they want to use Mozilla. Users can make educated decisions about whether Mozilla is secure enough for him/her. Holding back the bugs is like saying: "Mozilla is secure enough for you (end users)," Mozilla developers. Which of course takes away some freedom. Although users have the option to just not use Mozilla until the bugs are fixed or disclosed.
To me this sounds like a marketing decision. I imagine some Netscape suits do not want to ship Mozilla with known security bugs. So they have two options:
1) Delay the shipment of the new Netscape until the important security bugs are fixed.
2) Hide the bugs.
What would you do? Microsoft will hide the bugs. Netscape seems to be no better than Microsoft and will likely share the same fate (watch the next couple years for Microsoft's fate
--
May the source be with you!
Jason Zwolak
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!")
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