Slashdot Mirror
A Security Bug In Mozilla - The Human Perspective
xslf writes "Alex Vincent, the reporter of the data-loss security bug 259708, writes about the behind the scene process of reporting it, casting light on the problems of dealing with security related bugs reported by the community, which isn't always aware of the security implications of the bugs reported. The issues with the FLOSS process shown in this bug might get worse, once more and more people use FLOSS and add to the process, without being full fledged coders, and rely on binary releases of software." (Note, you'll have to copy and paste that link to view the bug report, or click through from the linked story.)
But I thought the very nature of OSS makes this sort of thing impossible. What did I miss?
There's a Mercedes gap too. I want one and can't afford one, but it's not government's job to do anything about it.
Um, that seemed to be the whole point. Again and again throughout the article he does a mea culpa. At the same time, I believe his general frustration with not knowing how to proceed comes through. We in FOSS need a more concrete process on how to handle bug through the system. And even very successful projects, like Mozilla/FireFox, can do a better job at communicating the way to handle these types of situations.
Gotta find my destiny, before it gets too late --Ian Curtis
http://www.shadowpublications.com/blog
timothy, IT's prodigal douchebag, is kind enough to tell all the slashbots to copy and paste the link to get past the referrer problem.
The editors here truly don't care, even when someone goes out of the way to make it clear they don't appreciate the rubbernecker bandwidth.
I don't need no instructions to know how to rock!!!!
Wait a sec, you're bitching that they won't pay you to work for them, when you don't pay them for thier product?
Holy hypocrisy...
feh. stuff.
Fantastic. Talk about having your cake and eating it while telling everyone they can't have any.
That Mozilla has a _huge_ number of bugs, many of which have existed for a number of years, a lot of which probably won't be fixed any time soon. Those working on the project don't generally care about them enough to fix them -- this is, after all, "only" a denial of service bug (note: I'm not condoning or excusing this behaviour, just saying that this is how a lot of people think).
Hmmm. That's a rather difficult conclusion to reach if you really read the article and think about it. Alex accepted the blame where he messed up, and noted other places he wasn't sure about.
The fact is,the other person should not have reposted someone else's blog entry without permisison.
The article was quite insightful. Hopefully it will lead to a better process.
This guy made the #1 mistake you can make when it comes to bug advocacy. He assumed his bug was more important than all the others. It had to be fixed now! Now! Now! Now!
Which can be entirely correct, but you don't get anywhere by running around like chicken little trying to make everybody look at your bug. They heard you the first time. If you don't have any new substantive information to give them, sit back and relax. People never respond to selfish requests well. It can even discourage them from taking a look at it.
As he tried to convey in the article, the issue is not whether he can be faulted or not (and indeed, he can; then again, you can expect that many/most bug submitters would make "mistakes" like these).
The quote, however, deals with someone who submitted for his weblog a word-for-word copy of his original bug report, without any comments, return address, or source. That goes a bit beyond useless and unhelpful, IMHO; that borders on disrespectful. At the very least, as he is saying, if that person indeed wanted full disclosure, he should point to where he found the copy of the text, so that the Mozilla security team could be made aware of it.
Overall a well written article, certainly a lot more thoughtful than your comment.
-tor
This bug was a security bug in part because Firefox 1.0 changed the default download directory so that downloadable files were saved directly to the desktop.
Microsoft is always criticized for having bad defaults. In this case, having the default download directory be the desktop was a bad default. I would argue that you wouldn't neccessarily do bad to create a folder for each downloadable file. No one would be annoyed by that, and it would provide protection in the file system for any future holes.
You could also have a "recently downloaded files" directory on the desktop. Even a shortcut to "Location of downloaded files". Mozilla has been known for its innovation. Using the desktop is not innovative--the desktop should never be a permenant storage location. Everything Microsoft puts there is a shortcut.
I also question whether it was wise to change or set defaults in a "1.0" milestone release.
First off, if someone reports a bug, it should be ASSUMED that there is a potential security issue there, until proven otherwise. Why? Because there are generally side-effects. Even if the bug doesn't directly do anything nasty, it may very well cause something unintended which, in turn, causes something else unintended, and so on. Programmers generally talk of such effects "cascading" or "snowballing", because the effects usually do build up over time. Sooner or later, this will result in a corruption of data, a program crash or an exploit due to insufficient value checking.
There are two classes of bugs in a computer program. Those that cause the program to crash, and those that don't. The second type are much harder to track down (because you've no real indication of where the problem started), but they are generally much worse and much more prevelent.
The "correct" way to handle bugs is to assume that (almost) any problem puts the software at risk of a non-fatal bug that could (eventually) destabilize the program or open an exploit. Spelling errors in text messages are probably OK, but even there, if you're placing them in fixed-length buffers, it is saner to check and be sure that the risks are low than to ignore apparently trivial "appearance" stuff that could be catastrophic. I've seen programmers give themselves buffer overflows, I've even seen programmers rely on certain OS quirks when an overflow occurs. The code may not be portable, and it sure as hell isn't safe, but it does work.
(I've actually seen some code that won't run, unless the debug flag is present. The code will actually segfault if the extra padding the debug data creates is not there. Not from the Mozilla team, this was in a prior place of employment, but it does demonstrate that coding is not just about making something "work" it's about making it work for the right reasons.)
Now, the Mozilla team is probably simply too small to regard every bug entered in their database as a potentially critical show-stopping security hazard. This, however, reflects more on the userbase than on the Mozilla folks. Open Source works if, and only if, the "lots of eyes" out there looking for problems also translate into "lots of hands" for fixing problems.
Sure, not everybody is going to be a coder. So? If a mere 1 in every 100 users took the time to chase down not only the bug as seen, but at least some of the prior bugs that that bug depended upon to do anything at all... Mozilla would be in a lot better shape.
Politics in projects don't help. GCC and Glibc suffer badly from a management style that can be diplomatically summed up as "Old-Style IBM without the money - or the justification". There's a lot of "Not Invented Here", "Somebody Else's Problem" and "It Works For Us", although the GCC team is apparently a lot better than it used to be.
The moment any project suffers from any of those three things is the moment that it is under a self-imposed sentance of death, to be carried out the moment a better alternative arrives, where the only possible hope of a reprieve is to tackle those attitudes and eliminate them.
9 out of every 10 security bugs are caused by a fault in attitues, at the time of coding or later, and not by any fundamental nature of computing.
BTW, this is off-topic, but biologists and geneticists are mourning the passing of one of the three scientists who discovered the structure of DNA. The BBC is reporting the death of Professor Maurice Wilkins, aged 87. He died in hospital, no cause was given.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
"not ... a remote-data-access."
According to comment 58 in the bug report: "Given that this vulnerability actually allows sites to do useful things like steal passwords, I feel that we should address it ASAP."
This bug allows the browser to open and access a local file. The information about the file can then be sent to a remote site with some basic javascript. How is it not a remote data access again? The DoS issue is not good, but the file opening is worse, particularly if someone figures out a way to get the contents of the file rather than just the characteristics.
I'm flabbergasted that the mozilla security people seem to think that "hiding" a previously public bug after it's noticed that it has security ramifications is an effective way to keep black hats from noticing it.
I think it's safe to assume that black hats interested in finding 0-day security holes in mozilla have already, or soon will create a mirror of the bugzilla archive, with history. Then they can look for bugs that are suddenly removed from the public bugzilla archive, and have some very good candidates for fresh security holes.
And there's no way the mozilla security people can effectively combat this. At best they get into a technology arms race with the black hats, trying to figure out what techniques they're using to spider and mirror the archive.
Once a bug is posted to a public bug tracking system, even if it's only been there for an hour, you might as well give up and assume it's widely publically known.
Oh and in my personal experience, the best way to get a security bug fixed once you discover it is to immediatly write an exploit, clearly flag the bug as a security hole, and post it to a public forum with a sifficuently broad readership that someone in a position to fix the bug will, be that the project's BTS or bugtraq.
see shy jo
"I might lose my $HOME"
Please tell me why losing all the documents/files/data you personally created is better then reinstalling an OS/apps, which are available on CDs and the net?
Hopefully, you have a good back-up plan, but my personal files are 100x more important then any 3rd party binaries.
IMO - both situations are equally terrible.
It is not different. If more people stopped running under an administrator account the great majority of IE vulnerabilities would result in the same thing. Most email worms would as well.
You can happily run under a non-privileged account in Windows NT4 and higher. The opearating system has supported it for at least eight years. That most applications break under such a scenario is Microsoft's fault to a certain extent, but not entirely so. Software vendors are just too lazy to code that way and they assume that they have the go of the entire machine.
I would like to point another type of hypocrisy however - whenever there's a bug in a Microsoft product that is not "critical" in the sense you use, the slashbots come out of the woodwork claiming it's the end of the world yet again. But a bug in Mozilla that wipes out ~/ is OK, because it's "not critical". Do you really think it's "OK" for the average user to see their files wiped while /sbin is untouched? Tell you what: they would not. They'd rather have to wipe the machine and see it turned into a spam zombie than lose the vacation pics and whatever else they have under there.
The problem with your assesment of this problem is that you say "user" and you're thinking about a developer or a sysadmin (in a corporate environment perhaps) with nightly backups and whatnot. In that scenario this bug is a nuisance. In reality it's a disaster.
Yes, ideally all bugs are fixed even more rapidly. But originally this wasn't marked as a security bug, and nonsecurity bugs often take more time to fix than you'd wish in any development process:
What changed everything was marking it as a security requirement. Here I agree with the author - the author should have identified this as a security problem in the first place. And I'm really sympathetic to his sitatuation; we all make mistakes, and at least he reported the bug in the first place. Thankfully, a later reader DID realize this, and raised it to a security issue. As a security issue, suddenly the "unlikely" problem becomes "near certainty" since an attacker WANTS to cause trouble, and will work to cause the unlikely to happen.
And once it was labelled as a security problem - look at the speedy response! It was fixed in less than a half hour - that's extraordinarily fast in any software development process, OSS/FS or proprietary. It's even more amazing because the problem was in a completely different place than 3 previous developers had thought... so this was clearly not an easy bug to find and fix (at least for most project developers).
And Firefox is still at the "previous release" level, it's not even officially released! I routinely use Mozilla and Netscape, not Firefox, because Firefox THEMSELVES state that the product's not ready. When they say it's ready, I'll let other people try it out first; version 1.0s are often a little wet behind the ears (remember Windows 1.0? Probably not, and there's a reason for that). But once Firefox 1.0 is out for a little while, I'll probably switch to it; it looks really nice. Obviously a lot of people
Getting ansy about taking a little extra time to find a non-security bug, when the product can't be released til it's fixed anyway, and it's hard to fix, seems a little excessive.
The process issues he raises are interesting issues, and they're certainly worth addressing. E.G., how do you "make secret" that which is already public? But I'm sure there are many possible answers; discuss, pick one, and move on.
- David A. Wheeler (see my Secure Programming HOWTO)