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

Don't link to bugzilla!!!

[AKAImBatman]

What are you trying to do? Shut down the Mozilla project?!? If you absolutely NEED to see the bug, go to MirrorDot and look it up there.

Re:Don't link to bugzilla!!!

[Anonymous Coward]

What's the difference? They block referrers from Slashdot anyway.

Re:Don't link to bugzilla!!!

[AbbyNormal]

Thanks for the mirrodot link. After finishing my fifth epileptic seisure from the pinstripes, I was finally able to read the bug.

3.5-year-old information disclosure and DoS

[Jeffrey Baker]

Speaking of existing security bugs in Firefox & Mozilla, here's a security bug that's been open for 3.5 years and really needs some hero to come in and fix it. (The bug is assigned to me but I'm not qualified and don't have the time to come up with a real solution).

Bug 69070

The bug was on bugtraq in 2001! It allows remote pages to open and use files on the local machine, and is also a denial of service on Linux, since Mozilla stupidly allows the opening of paths which are not regular files (/dev/tty).

My experience with 69070 has been educational. I've learned if there's a security bug you care about, you had better fix it yourself. Unfortunately I can't but maybe someone in the audience has the spare time to step up.

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.

Re:3.5-year-old information disclosure and DoS

[Anonymous Coward]

"It allows remote pages to open and use files on the local machine"

You make it sound like it allows remote servers to open and use files from the local machine. In fact what it allows is remote server to cause the local machine to open files locally, which is a different thing altogether.

It still should be fixed, but it's only a DoS, not a remote-execute or a remote-data-access.

Re:3.5-year-old information disclosure and DoS

[daserver]

You could just have written: hypocrite :-)

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.

I will save this bugtrack for later reading..

[Tei]

Opps.. where are ALL my precious precious downloaded files?

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

There's that FLOSS word again

[h00pla]

I really hate that acronym. FLOSS reminds me of brushing and FLOSSing (ie - picking the crap out from between your teeth). Is it really too much to ask to write out Free and Open Source software or how about Free/Open Source software? I can just see what's next - we'll be referrring to some development process as ENEMA.

Acronym loving developer: I advocate the use of FLOSS and if it's with ENEMA, all the better.
CIO: You're fired.

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:My experience reporting bugs..

[d_jedi]

Wow.. one post, so much criticism. I honestly haven't experienced that on /.

Guess it's not a good idea to criticize Mozilla developers ;p

OK.. allow me to respond to all of the replies in one post.

1) Bug reports = good. Insulting bug reporters = bad.

As a developer, I'll tell you that having your customers report bugs to you is a GOOD THING. Something that you want to ENCOURAGE. There is no amount of alpha or beta testing that can substitute for real world use. However, I've been encouraged by this experience to very much just "shut up and take it or leave it" (paraphrasing from one of the more colourful indignant replies I alluded to). I'm not going to report more bugs if this is the response I'm going to get to them. Which is a BAD THING for the Mozilla project.

2) Encouraging and reminding developers = good.

Developers are human beings. They can forget, get distracted, etc. And like all people, sometimes it's a good thing to remind them of outstanding issues. Perhaps they forgot about it? Perhaps they've completed the task, but haven't checked it in? Perhaps the guy responsible for the bug has too much work on his plate, but is reluctant to say so without being prodded.

Certainly, a post every few days asking if the bug's been fixed is just about as annoying as "are we there yet?" queries on car trips with children. But that was not the case here.

3) There ARE paid developers working on Mozilla

Most of them work for Netscape. I wouldn't doubt if there were contract workers as well. Personally, as an independant developer, I don't have the time or resources to program if I'm not being compensated for it. The question was asked why I don't fix it myself, and I gave a truthful answer. As a result (as here on /. ) I was flamed.

I hope this clears up any confusion.

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.

The headline makes me laugh

[wazzzup]

Today's Headline - A Security Bug In Mozilla - The Human Perspective

Tomorrow's Headline - A Security Bug in IE - Sweet Jesus, Microsoft Fucking Sucks Yet Again

Don't worry, I hate Microsoft too ;o)