A Bad Month for Firefox

marty writes "Februrary is not a good month for Mozilla developers. Infoworld reports about the efforts of Polish researcher Michael Zalewski, who apparently kept finding new vulnerabilities in the popular browser on a daily basis through the month, first postponing the 2.0.0.2 update, and then finding a remotely exploitable flaw in it immediately after its release."

Comments

Bottom line

[AndyBassTbn]

Bottom line - the more people use Firefox, the more people look for bugs and vulnerabilities, the more people find them. The same thing happened with IE.

Granted, I do think Firefox is far superior to other browsers on the market, but I don't think that this should surprise anyone. At least Firefox is being fixed quickly. I suspect other software companies may not have held back their release times on upgrades to fix additional bugs. ("Don't worry now, just get this new version out before the deadline, we'll fix it later...")

Re:Bottom line

[Mateo_LeFou]

"the more people use Firefox, the more people look for bugs and vulnerabilities, the more people find them. The same thing happened with IE." Except that with the Fox, half of the people looking for and finding bugs are doing so in order to help get them fixed.

A bad model?

[Lord Satri]

Well, such headlines won't stop me from using FF. At least vulnerabilities are attended to in a way I believe (wrongly?) faster than most mammoth companies would. That said, this point from the article is interesting, making me believe researchers should (?) have incentives to disclose security bugs to Mozilla first and to the public only when the fix is distributed:
"Although Snyder said she would prefer it if Zalewski and other researchers would disclose vulnerabilities to Mozilla before taking them public, she said the company relies on such experts to help it keep customers protected from attacks, as painful as the reports may be."

What's worse?

[tomstdenis]

As the author of security software, I'm not happy to find flaws in my code, but I'd rather find them then not.

The measure of success is whether the bug(s) found in Feb are new additions added by sloppy coders, or legacy bugs that have so far escaped notice?

Tom

How is this bad?

[El Cubano]

Could someone please explain how finding and fixing bugs/issues/problems/whatever is bad? Now, I understand that it is not particularly good from a PR perspective. However, it is not like they are ignoring these things or trying to spin it like they are not real problems (as certain commercial and proprietary software vendors are prone to do). This is, in fact, quite good for the users.

Re:How is this bad?

[Cid Highwind]

In short, Zalewski seems to believe in full disclosure instead of responsible disclosure.

So do most of us here at /. when it comes to bugs in Windows or IE or Java VM. Why not Firefox?

Some of these bugs were initially reported in 2001 and were only fixed in Firefox 2.0.0.2, six years later. The lesson here seems clear to me: Reporting security holes on bugzilla get them marked DUPE/WONTFIX/NOTABUG and ignored for 5+ years. Publishing detailed explanations of the exploits on your blog gets them fixed within a few weeks.

Bad month? No...

[onion2k]

Good month. Finding lots of bugs, and fixing them, is a good thing. We don't need to pretend it's perfect and rosy and all nicely secure and won't ever need a patch or an update. We're realists on this side of the OSS fence. We know that software is only as good as the people working on it.

I'd like to extend a hearty thank you to this researcher for making Firefox even better.

Bad month ends up with a good product.

[SoupIsGood Food]

Buffer overruns happen. Security models have holes. This is nothing new, and you'll find it in damn near every software project of any complexity.

The rational ways of dealing with this are a very dictatorial style of project management to get it right the first time (See: OpenBSD) or a quick and responsive way to kill security-affecting bugs dead. Firefox, with its gazillions of volunteer and paid programmers, opt for the latter. Too often, closed source developers just sit on these bugs, or sue the people trying to find and publish them, or use their marketing department to cover for their developers' shortcomings.

I'm pleased and reassured that Firefox is having these issues. Active and open security research will always result in a stronger product, and delays to deal with them are acceptable so long as the software is better for it. Even OpenBSD's been hacked a few times, and it's how you deal with it that's more important.

Microsoft's stuff is broken for =years=, which allows a security nightmare. Firefox is broken for a few days, or a month or two... too quick for all but the most dedicated and talented black-hats to take advantage of. Give me this over Internet Exploder any day.

When will we see a stable and secure project? That's an important question when dealing with closed source products. On something like Mozilla, with an open development model, the project goals and progress aren't company secrets... we actually know exactly why something has been pushed back, and can make reasonable judgements about when it will be back on track for ourselves. This is one of the more important aspects of open source that corporate IT overlooks... the ability to plan for and work around changes in the release schedule.

So, yeah, setbacks happen. To everyone. How the setbacks are dealt with is where the rubber meets the road. Firefox is generally ahead of the industry here, too.

Re:Bad month ends up with a good product.

[Anonymous Brave Guy]

Buffer overruns happen.

Not if you use proper design techniques, or programming languages where they aren't a possibility. Saying "buffer overruns happen" is just a concession to current poor programming practices. Better ways to do things have been known for a long time, it just requires more effort to use them when most of the world isn't yet.

Security models have holes. This is nothing new, and you'll find it in damn near every software project of any complexity.

That's true, but not every software project makes grand claims about having better security than the opposition. There is little text on the Firefox home page, but one of the three big headings is "Stay secure on the web". "Firefox continues to lead the way in online security," it tells us. Clicking through the link finds explicit claims about the open source model and the use of "security experts".

Microsoft's stuff is broken for =years=, which allows a security nightmare. Firefox is broken for a few days, or a month or two... too quick for all but the most dedicated and talented black-hats to take advantage of.

And how do you know that all of these Firefox bugs have only been added recently, and haven't already been exploited by black hats before they were announced? Do you personally check into the background of every bug report in Firefox? Do you think everyone who uses it does? How many serious vulnerabilities in IE are really open for years? Do you have stats to back this up, or are you just a Firefox fanboy spreading FUD? These are, after all, exactly the criticisms commonly levelled at IE.

When will we see a stable and secure project? That's an important question when dealing with closed source products. On something like Mozilla, with an open development model, the project goals and progress aren't company secrets...

So all security bugs in the Mozilla family are immediately and openly disclosed to the public?

Re:Your model is bad.

[Albanach]

if you disclose the problem to the public, they can't do much apart from switching to another product or wait until microsoft developer finally fix the problem.

But that's only an issue if you get no response. What if MS email and say thanks, we've looked into this, we need to change x, y and z and it should take about two weeks before we issue a fix. What would be the advantage in going public inside those two weeks?

I can't see any valid reason for someone not to report to Mozilla first, and to expect a reasonable and speedy response, then oing public if a fix is not in place inside a sensible timescale. To do otherwise suggests the researcher is more interested in self publicity than in protecting users of the browser.