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.)

Comments

Re:Looking for blame in all the wrong places

[mobiusjava]

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.

Re:My experience reporting bugs..

[kmmatthews]

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...

Re:3.5-year-old information disclosure and DoS

[The Bungi]

Interesting. People around here bitch about Microsoft having these "dozens" of "unpatched vulnerabilities" in IE for "years" and "hiding, lying" and "sitting on security issues" and here's a three year old bug in the darling of open source development, who also has a "security classification" for certain bugs that "should not be disclosed" until they are fixed. But it's OK for some dude to publish an IE vuln without first contacting Microsoft and giving them a chance to fix it (which they have been doing very diligently for the past two years), in fact it's fantastic because it makes Microsoft (or "M$") look all the worse. But if it's Mozilla, it's perfectly acceptable. The recent GUI spoofing vuln (related to XUL, I believe) published a few months ago also had a "security classification" and was at least three years old, IIRC. But that's OK, because it's Mozilla.

Fantastic. Talk about having your cake and eating it while telling everyone they can't have any.

Yes, you are...

[Roadkills-R-Us]

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.

IAAPST (I am a professional software tester)

[Anonymous Coward]

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.

Re:IAAPST (I am a professional software tester)

[joey]

Bugzilla seems to encourage this with its system of various ways of voting on a bug, which encourages users to advocate their pet bug in order to get it fixed. I've seen this advocacy spill over into projects that don't use bugzilla recently, and IMHO it just causes a lot of distracting noise.

smart defaults

[osssmkatz]

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.

Re:3.5-year-old information disclosure and DoS

[CaptainABAB]

"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.

Actually, things went really well.

[dwheeler]

The author makes the process (from the user point of view) sound much worse than it really was. Was this a bad bug? Of course, all agree that dataloss is a terrible thing. But:

1. this was immediately marked as a blocker, so the official (initial) release of Firefox was NOT going to go out with this bug, anyway, no matter what.
2. once it was identified as a security issue, it was fixed within a half hour, even though it was an incredibly difficult bug to find (3 project developers had tried and failed).

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:

1. The bug appeared to be an extremely unlikely occurance, and thus while important to fix before release, it's not clear that the delays were in any way unusual for ANY development project. Although it had bad ramifications, it's also clear that triggering this accidentally is extremely difficult. None of the millions of users using Firefox had reported it before, and previous versions have been out for a while. The priority of a bug doesn't just depend on the severity of the problem, but on the likelihood. If a dataloss can happen 1/day, that's much more serious than one that happens 1/millenium. For extremely unlikely triggers, it's not at all unusual for those to take longer to correct in either proprietary or open source software. In part that's because of the difficulty of tracking down such uncommon problems to their source.
2. This was obviously a hard bug to fix. Three people tried to find the bug, and couldn't do so. The author wishes that even more people would've worked on it in the early days, but all projects have a limited number of people and much to do. Heck, in most proprietary projects, you assign only one person to handle the bug, and that person has 100 other assignments too. He had three people directly working on it, with discussion by others... that's far more help than many projects get.

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.