Slashdot Mirror


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

13 of 195 comments (clear)

  1. Bottom line by AndyBassTbn · · Score: 5, Insightful

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

    --
    I hope the land around you yields, a crop like all the other fields, and then your waiting might make sense...
  2. Bad month? No... by onion2k · · Score: 5, Insightful

    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.

  3. Internet Explorer by bitsformoney · · Score: 5, Funny

    Solution: Stick with IE. Shoudda known.

    --
    This comment is printed on 100% recycled electrons.
  4. Re:How is this bad? by bunratty · · Score: 5, Informative

    The only bad thing is that Michael Zalewski is not following Mozilla policy for reporting security bugs. He should first report them to Mozilla privately and give them some time to fix the problems. Instead, he publicly announces the vulnerabilities so the bad guys can exploit them before Mozilla has any chance to fix the problems. In short, Zalewski seems to believe in full disclosure instead of responsible disclosure.

    --
    What a fool believes, he sees, no wise man has the power to reason away.
  5. Bad month ends up with a good product. by SoupIsGood+Food · · Score: 5, Insightful

    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.

  6. Re:What's worse? by tomstdenis · · Score: 5, Interesting

    Well yeah that's the flipside. Some people report "bugs" which are things that cannot really be exploited in the field [e.g. unreachable exploits]. I deal with that in my OSS work as well. Though, usually I fix them anyways just for completeness. In fact, a non-trivial amount of bugs I've fixed have been of that sort [I wouldn't say a majority but definitely not just a few].

    Some people like the press it gets for finding them too.

    That being said, some projects react bad to bugs. GCC is an example of a group who react well to them. I've had several PR's fixed because of a simple ICE or asm dump I sent in. Whereas in the Linux camp, bug fixing is a royal right only a few can have. When I wanted to add device IDs for Intel NICs to the 2.6.18.2 [iirc] kernel I submitted a patch which added them. It was refused saying that they would be added in the next major release cycle. Even after I told them that they could trivially be added to the next point release they still refused. Oddly enough the maintainer, a Gentoo developer, added them to the gentoo brand of the kernel anyways. Go co-operation!

    I dunno, for me it's a sense of responsibility. If I'm going to release software that can potentially cause problems for others, I make sure I respond to valid reports as soon as possible. I don't look at it as a negative experience because for me the alternative is to stop sharing the code alltogether.

    Tom

    --
    Someday, I'll have a real sig.
  7. Re:Your model is bad. by Albanach · · Score: 5, Insightful

    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.
  8. Re:How is this bad? by Cid+Highwind · · Score: 5, Insightful

    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.

    --
    0 1 - just my two bits
  9. Re:Compelling reasons to switch to 2? by kv9 · · Score: 5, Informative

    You're also missing the annoying UI design and worse performance.

    I agree that the UI is not the most pretty thing ever envisioned (why does everyone go for ROUND shit now? let me guess, the UI designers have Macs) but performance wise it got better. also it's more stable and the integrated session management allows you to get rid of all the clunky extensions that tried to provide sessions (along with the kitchen sink)

    there's also tabbed browsing improvements and other features. GP, check the changelogs.

  10. Re:No we're not by Mateo_LeFou · · Score: 5, Informative

    "Conclusion? Apache has predictably shown more vulnerabilities than IIS versions over the same time period"

    Conclusion? Apache has predictably reported more vulnerabilities than IIS versions over the same time period

    FYP

    --
    My turnips listen for the soft cry of your love
  11. Re:Compare against the best. by omeomi · · Score: 5, Informative

    But compared to Opera, Konqueror and Safari, it's still quite slow and extremely bloated.

    I use Firefox and Opera on Windows, Safari on OSX, and I have occasionally used Konqueror, but I'll admit, not as frequently. However, I've never noticed a perceptible difference in speed or obvious bloat between Firefox, Opera, and Safari. "quite slow" and "extremely bloated" are obviously complete fabrications...

  12. Re:How is this bad? by tetromino · · Score: 5, Informative
    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?

    No. I would venture to say that most people here believe in giving Windows/IE/Java/Firefox devs a couple of weeks to fix a bug before going public. Coming up with a patch is the easy part. Any large project will need to look for related issues in the rest of the code, to do QA work to make sure the patch doesn't introduce new bugs or vulnerabilities, and to package the updates for all the different architectures and products that happen to be vulnerable. That process takes time; it is physically impossible for the Windows/IE/Java/Firefox team to release an update the same day you informed them about the issue. If you go public on the first day, you are just being an asshole.
  13. Ruh-roh! by authority69 · · Score: 5, Funny

    Is Scobby Doo writing the posts these days? What's "Februrary?" The month after "Janrurary?" Right before "Marrrrrch?"