Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

611 Defects, 71 Vulnerabilities Found In Firefox 434

Danny Begonia writes, "Some folks at Klocwork examined the large and complicated code base of the popular open source browser, Firefox. Overall, Firefox is a well written and high quality piece of software. Several builds were performed on the code, culminating in the final analysis of version The analysis resulted in 611 defects and 71 potential security vulnerabilities. The Firefox team has been given the analysis results, and they will determine if or how they will deal with the issues." What are your thoughts — do Firefox and the open source community welcome this kind of analysis?
This discussion has been archived. No new comments can be posted.

611 Defects, 71 Vulnerabilities Found In Firefox

Comments Filter:
  • Obvious. (Score:5, Insightful)

    by keyne9 ( 567528 ) on Thursday September 07, 2006 @11:52AM (#16059739)
    do Firefox and the open source community welcome this kind of analysis?

    Obviously, yes. Otherwise, open source would be closed-source.
    • Re:Obvious. (Score:5, Interesting)

      by legoburner ( 702695 ) on Thursday September 07, 2006 @12:01PM (#16059852) Homepage Journal
      Especially now that firefox is so popular. Firefox makes up 10% of users on the general Internet (as counter by []), with IE at 85%. My own tech related site [] has 76.4% of users using firefox, with just 10.1% on IE, and my other more casual site has 23.1% firefox and 64% IE (the rest being safari, opera, konq, etc.)
      • Re:Obvious. (Score:4, Funny)

        by Anonymous Coward on Thursday September 07, 2006 @12:05PM (#16059893)
        And thanks to the popularity, now adware is built for Firefox as well. Especially that Yahoo crap. Bleh!
        Like the kid that was goth before it was popular, it's time to change to a more obscure web browser.
      • Re:Obvious. (Score:5, Informative)

        by Danga ( 307709 ) on Thursday September 07, 2006 @12:45PM (#16060213)
        I wouldn't trust those numbers from or any of the other sites that depend on user agent. Opera user here and I know for a fact that most of the time I have my user agent set to MSIE 6.0 otherwise a lot of sites give me problems and won't let me load them even though they render just fine. Those same sites a lot of times will load without a problem in firefox, when will web designers stop checking the damn user agent, it is a waste of time and just pisses people off. It has been getting better but still any analysis done that relies solely on user agent is not reliable in my book. I also would really love to have a true way to find out how close that 1% for Opera is to correct because I doubt it is correct.
        • Re: (Score:3, Insightful)

          when will web designers stop checking the damn user agent

          A) When they get a firm grasp of the CSS box model and its quirks. This is a developer by developer evolution.


          B) When the CSS support and compliance across browsers begins to share a larger commonality. Large enough so that browser quirks are moot points.


          C) PHB's who come up with the site specs quit taking the lazy way out and telling their developers/designers to "just make it work in IE" so they can meet their deadline.
        • by Chuck Chunder ( 21021 ) on Thursday September 07, 2006 @03:40PM (#16061569) Homepage Journal
          Even when Opera is spoofing it's user agent string the text "Opera" is still in there [] and anyone making a reasonable effort to identify browsers will be able to count it accordingly. Opera's spoofing doesn't hide that it's Opera, it only acts a workaround for sites that only detect a common part of the IE/Mozilla UA string and wouldn't do anything if one of those aren't found.
    • by Billosaur ( 927319 ) * <`ten.enilnotpo' `ta' `rehtorgw'> on Thursday September 07, 2006 @12:01PM (#16059854) Journal

      Obviously, yes. Otherwise, open source would be closed-source.

      The numbers look large given that Firefox is supposed to be the superior browser, but can you imagine what those same numbers would look like for IE? Think Gates & Co. would care to give up the source code to do a head-to-head comparison? I'll bet the folks in Redmond are looking at these numbers and wondering just how to get IE's numbers that low.

      • by rucs_hack ( 784150 ) on Thursday September 07, 2006 @12:54PM (#16060293)
        slightly OT I know, but relevent:

        Back when I was a nurse, in the days before programming sucked me in, I was a manager in a private elderly care home for people with dimentia.

        We kept excruciatingly detailed records of every scratch, cut and injury, serious or otherwise, that happened to our clients. So much so that on paper our accident record look awful compared to other homes, who tended not to be so open. We actually had fewer such incidents then other homes in our region, but we documented *everything*.

        However, come official inspection day, the health authority inspectors were always very pleased with our records, and always passed us with a very high grade.

        The reason? Instead of hunting around for hidden evidence that had been concealed, they just had to consult our records.
        We were open about problems, and always sought solutions. We were also, because of our policy on recording everything, able more easily to identify problems with patients who were more likely to get cut, and work to alter their environment or diet to try and help.

        The result was that we ended up being the top specialist care home in our region.

        When I moved into computer science, the only software model that I would work with was open source. Again there is nothing gained from hiding problems with code, and it's much easier to identify issues. I discovered remarkable similarities with my old nursing practices and the Open Source method.

        I realise the comparison may seem odd, but my point is that being open about problems is a far better way to reach solutions, whatever field it is applied to.
        • by ScrewMaster ( 602015 ) on Thursday September 07, 2006 @01:32PM (#16060608)
          I realise the comparison may seem odd, but my point is that being open about problems is a far better way to reach solutions, whatever field it is applied to..

          That is actually an excellent example (and hardly off-topic) but in that case as well as software development, it only works when those responsible are actually interested in finding solutions. Far too often the goal is simple suppression of any negative information. That can be for any number of reasons, but true openness requires a degree of, well, maturity that is in rather short supply nowadays. It doesn't help that there are thousands of hungry attorneys out there just waiting to pounce on any misstep (from a purely legal perspective, honesty is not necessarily but the best policy.)
    • Re: (Score:3, Insightful)

      by ClamIAm ( 926466 )
      Well, there's certainly some developers who get pretty bitchy when you file bugs or point out errors they've made. Does that make their project(s) closed-source/proprietary? No.

      But the bigger point here is basically this: Slashdot editors appending a leading/flamebait question onto a story generates more responses, and more ad impressions, and hey look I fell for it too.
    • Agreed. The real question here is why does a /. Editor even need to ask that question?
    • Re: (Score:3, Insightful)

      by ztirffritz ( 754606 )
      I know that the parent's comment sounds obvious, but to some people it isn't. This is EXACTLY why open source is a better development model. This will lead to a stronger product in a shorter time frame. Yes it creates some more work, but this type of work is never complete.
    • by msobkow ( 48369 ) on Thursday September 07, 2006 @12:22PM (#16060018) Homepage Journal

      The biggest push I've heard given to corps over the years is not that OSS can be modified, enhanced, integrated, or reused, but that it can be inspected, reviewed, and fixed.

      If there is anyone working in OSS who doesn't appreciate receiving such an analysis of potential bugs, then they shouldn't be programming anywhere. Whether for fun or profit, fixing the bugs and adding features is what the "job" is.

      • Re: (Score:3, Insightful)

        by ronanbear ( 924575 )
        As long as the vulnerabilities aren't disclosed publicy without allowing the developers the chance to decide what to do they should be very happy.

        This audit/analysis has tracked down bugs and problems that might have taken a much longer time and much more effort to find. Now developers time can be spent fixing problems instead of finding them (which they should still do, naturally).

        • Re: (Score:3, Insightful)

          by msobkow ( 48369 )

          It's OPEN SOURCE.

          The vulnerabilities are there for anyone to find, so not disclosing the results in a reasonably short time frame so they can be fixed would be irresponsible. Hiding vulnerability reports is only advantageous to closed source, where the crackers can't see the problematic code.

  • Memory leaks (Score:5, Interesting)

    by Anonymous Coward on Thursday September 07, 2006 @11:53AM (#16059748)
    It seems mainly the problems were to do with memory leaks. Which having seen firefox eat 700mb of ram doesnt surprise me....As long as these probs get fixed i cant complain...Doning this kinda of analysis is much easier with the source code i imagine.
    • Re:Memory leaks (Score:5, Insightful)

      by kripkenstein ( 913150 ) on Thursday September 07, 2006 @12:02PM (#16059866) Homepage
      TFA mentions 80 possible memory leaks and 54 certain ones (as certain as you can trust their software, but that's something else). That doesn't sound like very much for a large project like Firefox. Still, Firefox does seem to use more memory than it should, at times. Perhaps these newly-identified defects are related to such behavior?
    • Re: (Score:3, Interesting)

      This and the God-damned copy and pasta bug!!! Firefox devs fix this one long term bug and I will sacrafice some cattle. I swear. Its driving me nuts..
    • Hi troll, I'm not going to bite but instead redirect you to a useful Firefox wiki [].
    • Re: (Score:2, Informative)

      by CCFreak2K ( 930973 )
      You seem to have forgotten that one of those leaks is actually a feature [].
      • by Z34107 ( 925136 )

        A cache of recently-visited pages is nice.

        Why they can't free up the memory the cache used AFTER THE BROWSER IS CLOSED is beyond me.

    • Seeing as how the development team pulled a Microsoft earlier this year and panned these memory leaks off as "features" [], I find it highly unlikely that they'll address them properly.
      • Re: (Score:3, Interesting)

        by Dan Farina ( 711066 )
        Except this isn't a memory leak, but is in fact intended behavior. A memory leak is a fairly specific and (and in this case) a non-applicable bit of terminology, unless there is more to that article and comments linked to that I'm not seeing. You could instead argue that the behavior is not a good one unless you point to a reference that shows that this memory usage is, in fact, caused by a leak.

        On one side of the fence are those who say ram is cheap and we shouldn't care, but when "big" becomes "too big" i
    • Re: (Score:3, Insightful)

      by supersnail ( 106701 )
      Ah the joys of mechanical bug tracking!

      What there software has identified is either paths through the code
      where the software given the right set of variables could just possibly
      leak memory , and, paths which when taken will leak memory.

      This does not necceserily translate to memory leaks in real life.

      Commercial products such as "purify" have been doing this stuff for years.
      The main problem with using these tools (apart from the queasy feeling
      you get when it generates a 200 lines of warnings and errors for y
  • YES! (Score:5, Insightful)

    by Total_Wimp ( 564548 ) on Thursday September 07, 2006 @11:53AM (#16059756)
    What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?

    God I hope so. What on earth is the advantage of open source security if they don't get this kind of analysis?

  • Why Not? (Score:5, Insightful)

    by eldavojohn ( 898314 ) * <> on Thursday September 07, 2006 @11:53AM (#16059758) Journal
    What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?
    And why wouldn't they?

    Seriously, any free testing is better than none. Especially when they point out the problems explicitly and hand them to you. As a developer, you're then given one last chance to fix your product -- if these even need to be fixed. I would expect things like the 134 memory leaks to be fixed and fixed fast. I've known Firefox to occasionally go on a memory splurge at my computer's expense and have expected this to be the problem. As far as some of these other problems that are mild security issues, they might not need to fix them at all.

    Even the article admits that a lot of these "issues" are trivial to fix:
    By far, the majority of the defects reported were null pointer dereferences (446 defects). A large number of defects resulted from the code not checking for null after memory was allocated. In addition, there were many cases where the return value of functions designed to return null were not checked prior to dereferencing.
    Sounds like a two week job of an intern to me. Checking for null and handling it after memory allocation could probably be a cut and paste job. If they mention the line numbers and files, there's your fix.

    Either way, this is the beauty of open source software, anyone can go in and do this. Now, if you found bugs in a proprietary program from some company and sent them a breakdown of problems, you'd get one of two responses. 1) No response and 2) A charge that you are reverse engineering their product and in violation of many anti-piracy laws. If the company still didn't address the issues and you published the bugs, then you're nothing but a software terrorist.

    So let's kick back and watch open source at its best! No software is perfect, but it will be enjoyable to know that a process like this can occur -- with the end result being a better free product on my machine!
    • Re:Why Not? (Score:5, Insightful)

      by RAMMS+EIN ( 578166 ) on Thursday September 07, 2006 @11:59AM (#16059840) Homepage Journal
      ``As far as some of these other problems that are mild security issues, they might not need to fix them at all.''

      Rule #2 of security: there is no such thing as "mild security issues".

      (Rule #1 is that the only secure system is no system at all)
      • Re:Why Not? (Score:5, Insightful)

        by ajs ( 35943 ) < minus berry> on Thursday September 07, 2006 @12:55PM (#16060296) Homepage Journal
        Rule #2 of security: there is no such thing as "mild security issues".

        This is unreasonable in the extreme. Security analysis is a matter of risk analysis, and to say that there's no such thing as a mild security issue is about the same as saying there's no such thing as a mild risk. Risks of all forms are multi-dimensional quantities, and yes it is possible to have a risk that is so mild that the trade-offs involved in fixing it are not worth the pain.

        Here's a great example: I can stand over your shoulder and watch you type your password to your 401k account in your browser. Firefox could address this "mild security issue" by having you pre-assign a dummy string which it removes from typed passwords. In any other browser that was not so configured the password you typed would fail to work, and the security problem would be greatly reduced.

        This is, however, not enough of an issue that it's worth it to firefox to take the lead in addressing it. Perhaps if some particular OS or desktop provided such an option as a user-level setting, then it would be worth picking it up and using it, but as it stands, there are bigger fish to fry.
    • Re:Why Not? (Score:4, Interesting)

      by arth1 ( 260657 ) on Thursday September 07, 2006 @12:11PM (#16059937) Homepage Journal
      Why wouldn't they? Ego, unfortunately. Open source developers are just as human as commercial developers, and don't like anyone badmouthing their babies.
      Yes, I expect a fair number of these bugs to be fixed, but I also expect a fair number of them to be closed without action, if there's any way to pass the blame.
      "Package A leaks memory when used with package B? Package B needs to free the memory we allocate. Not our fault. *CLOSED*"
      "Package A has a buffer overflow vulnerability? Packages B and C must filter the strings they send us. Not our fault. *CLOSED*"
      "Package A has a buffer overflow vulnerability when used with Unicode? It's designed as a single-byte character routine. If you want a multi-byte one, write your own. Not our fault. *WONTFIX*"

      I hope and trust that most of the bugs will be fixed without politicking and passing the buck, but I fear there will be quite a bit of focusing on blame placement and credit taking instead of getting a thankless job done.

      • Re:Why Not? (Score:4, Insightful)

        by Todd Knarr ( 15451 ) on Thursday September 07, 2006 @12:26PM (#16060054) Homepage

        "Package A leaks memory when used with package B? Package B needs to free the memory we allocate. Not our fault. *CLOSED*"

        Could be entirely legitimate to close it. If the spec says that package B shall take ownership of the memory when passed in, then yes a bug against package A for a memory leak should be closed and refiled against B that's not honoring the spec.

        "Package A has a buffer overflow vulnerability? Packages B and C must filter the strings they send us. Not our fault. *CLOSED*"

        Again possibly entirely legitimate. I've written a number of low-level routines that don't do much error-checking. This fact is explicitly noted in the API spec, and responsibility for error checking is explicitly placed on the caller. That's because these routines get used in performance-critical inner loops, and the error checking should only be done once outside the loop instead of every time the loop executes. That's easier to do if you hoist responsibility for the check up to the point where the data comes in, rather than pushing it down to the lowest level. But things like that do need to be spelled out in the spec, so users of that routine know what their responsibilities are.

        • Re:Why Not? (Score:4, Interesting)

          by Jerf ( 17166 ) on Thursday September 07, 2006 @12:50PM (#16060251) Journal
          If the GP is correct, it's still bad usage of the bug system. If Team A feels the fault belongs to Team B, the correct response is to move the bug to Team B, not to close the bug.

          They may get into a fight about whose responsibility it is, but such a fight is also a bug, as such responsibilities in such a large project basically are a part of the code and should also be clearly delimited. If you insist on using languages without automatic garbage management, "who's responisibility it is to deallocate this memory" is a fundamental part of the API.
          • True, but often either package B isn't in the same bug-tracking system or team A doesn't have authorization to move the bug to someone else's package. I run into this all the time at work.

    • Re: (Score:3, Insightful)

      by cheezit ( 133765 )
      "any free testing is better than none"----I don't think so. Automated code scanning tools generally have a high false positive rate, and each possible bug must be examined thoroughly to identify what the issue is. Sometimes the change required to make the tool shut up will not have an impact on the behavior of the application, but now you have to test all the code paths because you changed the code.

      Free testing is great ONLY if the time spent investigating each problem is less than the time it would take
  • Why not? (Score:5, Insightful)

    by gstoddart ( 321705 ) on Thursday September 07, 2006 @11:54AM (#16059760) Homepage
    Why wouldn't people like the fact that an independant group audited the code?

    At least with open source, you can do that. And, giving the report directly to the Mozilla people means that they know the issues are there and can address them.

    Better than security through obscurity where only the one who found the exploit knows it's there.

  • I value it (Score:4, Interesting)

    by jimstapleton ( 999106 ) on Thursday September 07, 2006 @11:54AM (#16059763) Journal
    as a user, I value this kind of criticism - it's better out in the open where the devs are pressured to do something about it, than behind close doors where those of malicious intent can go about their nefarious business unhindered.
  • Closed-source software companies are paranoid about this sort of thing. They are often openly hostile, to the point of suing anybody who does this sort of analysis.
  • MS Security (Score:2, Funny)

    by Anonymous Coward
    Right after they hired that Microsoft Security expert nevertheless!
  • Answer: (Score:5, Funny)

    by Anonymous Coward on Thursday September 07, 2006 @11:54AM (#16059774)
    > What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?

    No, they're going to sweep this under the rug and disappear anyone else who audits their code. What the fuck do you think?
  • Seriously ... this basically is free work in finding bugs some user with less well-meant ambitions could have found and not reported.
  • Of course it does (Score:5, Insightful)

    by Dark Paladin ( 116525 ) <<jhummel> <at> <>> on Thursday September 07, 2006 @11:55AM (#16059786) Homepage
    Does Open Source encourage this kind of analysis and input? Absolutely. I'll take it two steps further. As of now, the Firefox team can:

    1. Ignore the data.
    2. Use the data to make a better product.
    3. Look at the data, decide what is a true security issue/bug or not, and proceed on.

    And, then there's also the option for the users:

    1. Use Firefox as it is.
    2. Make their own version.

    The very idea of Open Source would, if there is a truly serious bug/security flaw that Firefox ignores, allow another group of people to fix the issue and release their own version - which could compete and even surplant the current Firefox version with the user base should people decide that's what they want.

    So, without appearing rude, I would state that the question is a silly one. Yes, Open Source encourages this kind of analysis of all kinds. It just has a built in process that allows action to be taken - even if the primary code developer does not want to.

    Of course, this is all just my opinion. I could be wrong.
  • False positives (Score:5, Informative)

    by interiot ( 50685 ) on Thursday September 07, 2006 @11:56AM (#16059794) Homepage
    Note that Klocwork, while definitely a good tool, does tend to produce a fair number of false positives [], so it's not possible to try to compare an automated report of potential problems to a list of problems actually agreed to be a problem and actually fixed by an organization.
    • by LWATCDR ( 28044 )
      I did notice that a lot of the errors involved assuming that an malloc didn't return null.
      While really bad practice it should only happen when a system runs out of virtual memory. If you get to that point the only real answer often is to terminate the program or abort the the current operation depending on what caused the error. If you do not detect the situation and try and use a NULL pointer you get a GPF which will terminate the program. Such a situation should be very rare and effect very few users. N
  • by kjs3 ( 601225 ) on Thursday September 07, 2006 @11:57AM (#16059804)
    What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?

    Of course they do. Closed source companies say "what's my profit motivation for fixing these, and how much is it going to cost me to do it, and what are the costs of not doing it". Open source projects (usually) don't operate under those restrictions, so there's little downside to having issues pointed out.

  • You have to know where the holes are to fix them. I can't see this being perceived as anything but good (improvements for Firefox now lie ahead) by reasonable members of the community. Sure, no one likes it when bugs are found in their code, but I would hope that most programmers genuinely want their code base to improve.

  • FTA:
    Only someone with in-depth knowledge and background of the Firefox code could judge the danger of a particular security vulnerability; therefore, I have not included more detailed information of these security vulnerabilities that could lead to the spreading of unfounded rumours of potential exploits. However, for those interested, I've provided more details of the defects below.

    Well here come the rumors. All software has issues, some more than others, but firefox is still less vulnerable than IE at pr
  • Copy, paste (Score:5, Funny)

    by Jon Peterson ( 1443 ) < minus cat> on Thursday September 07, 2006 @11:59AM (#16059830) Homepage
    Hey, if it makes them fix the copy/paste bug, it's all good by me.
  • by tcopeland ( 32225 ) * <tom@thomaslee[ ] ['cop' in gap]> on Thursday September 07, 2006 @11:59AM (#16059831) Homepage
    ...I recently wrote an article for Better Software (details here []) showing the duplicated code and some other static analysis-type problems that PMD [] turned up in two fairly popular open source Java apps - Azureus and Columba. Both these programs are excellent open source apps, but both also had a number of places that could be improved.

    This is kind of a Slashdot permathread, but anyhow, static code analysis is not a replacement for smart people also looking at the code. Rather, it augments folks' efforts and provides a safety net to catch little problems that can slip through. A duplicated code detector [] is especially useful because it can scan a massive codebase and help pick out chunks of code that can be refactored away. This reduces the lines of code, eliminates the possibility of duplicate bugs, and is great fun.
    • This is kind of a Slashdot permathread, but anyhow, static code analysis is not a replacement for smart people also looking at the code. Rather, it augments folks' efforts and provides a safety net to catch little problems that can slip through.

      I have no mod points, but I give you a "virtual" +1 on that.
  • Static analysis tools like the one used to produce this list tend to produce lots of false positives, because they can't make as many assumptions as a programmer who knows what's going on, and they can't follow most interactions between different modules. So the headline should be "611 *possible* defects, 71 *possible* vulnerabilities" found. More likely, a small handful of those will turn out to be real (but minor) bugs, and the rest will be bogus.
  • by PFI_Optix ( 936301 ) on Thursday September 07, 2006 @12:02PM (#16059867) Journal
    Firefox just crashed while I was reading this article.
  • Not too bad (Score:4, Insightful)

    by dctoastman ( 995251 ) on Thursday September 07, 2006 @12:03PM (#16059881) Homepage
    At first I thought "Great, another FUD piece overblowing what are probably trivial issues."
    The I RTFA and saw that it was an honest report of errors given in a straightforward and clear manner.
    And like other posters have mention, none of them sound that life-threatening.

    I'm sure some Microsofties are going to be spinning this wicked for the next couple of months however.
  • by bob whoops ( 808543 ) <> on Thursday September 07, 2006 @12:06PM (#16059900) Homepage

    What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?

    Not getting this kind of analysis isn't going to stop the bad guys from running them.

  • What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?
    What a way to get people to respond to a no-news article. Open-source project has bugs and vulnerabilities. Oooooh, what a shock. And I thought the source code of FF was handed to us by Moses himself :(
  • College Lab (Score:2, Interesting)

    I did a lab last semester where two computers where set up, one running IE, one Running Firefox. I attempted to hack both of them using the BackTrack distro... a linux distrobution with a ton of tools and hacks to test vunerubilities. The conclusion? It took me less than 5min to hack the Box using IE through the browser. Took me 4 days for Firefox.
  • by Loco3KGT ( 141999 ) on Thursday September 07, 2006 @12:14PM (#16059947)
    "Can't last more than 20 minutes on Myspace" bug?

    Yeah, that's right. I just admitted to using Myspace for more than 20 minutes at a time.
  • by Thrymm ( 662097 ) on Thursday September 07, 2006 @12:16PM (#16059974)
    Ive been in the QA field since 97.... no matter the complexity of the application, there are countless bugs, defects, etc.... in fact development in most cases welcomes the more found, hence the more fixed. There is a book on Amazon called the Art of Software Testing ( /dp/0471469122/sr=8-1/qid=1157645733/ref=pd_bbs_1/ 103-3570097-7021412?ie=UTF8&s=books []), which states no matter how many defects are found, it's probably not even half of what could be found with plenty of people testing an application. With an application like a browser where millions of users become testers of sort, this is bound to happen. So this doesnt bother me, as hopefully one would think the vulnerabilities and major issues will be fixed....
  • by alanjstr ( 131045 ) on Thursday September 07, 2006 @12:21PM (#16060013) Homepage
    Slashdot already had an article: Firefox Analyzed for Bugs by Software [], where Coverity did automated scanning. That was welcomed by the OS community, as well as by Mozilla who partnered with Coverity to incorporate this.
  • by jkeegan ( 35099 ) on Thursday September 07, 2006 @12:22PM (#16060022) Homepage Journal
    Well they certainly don't appreciate being reminded that they still don't support the disable-output-escaping feature of XSLT.. []
  • One of the top theoretical benefits of open source is the "Many eyes" method of bug spotting. And Klocwork provides an "electronic" eye. (I am imagining the Six Million Dollar Man sound effect here.)
  • 700 defects sounds like a lot, but most were probably not done by manually examining the code.
    More likely, it was a codebase scanner that checked for problems, such as memory leaks, double frees, stack issues, etc.

    The real question is, was the scanner likewise scanned for problems? :-)
  • I think this sort of stuff is great because the old practical advice of "getting an extra set of eyes" holds true, especially in technology. The tone of the report is professional instead of condesending, as so often I've seen on mailing lists when someone 'reviews' another's code. I imagine that this report will be well received by the Mozilla community at large. Even though the types of errors referenced in the report are common, it is still a great example of free software / open source philosophy workin
  • What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?

    I would think the answer would be "yes, absolutely so."

    Personally I've always thought people should make more extensive use of these kinds of automated code
    analysis tools. When there are classes of problems that can be found using fairly mechanical means that
    can be programmatically driven, it just makes sense to do so, IMO.

  • It's great that the Firefox codebase has been scanned, but surely Firefox also depends on other open-source libraries? If these are not also scanned then the analysis is incomplete (although still much better than nothing).
  • Remember that all errors do not have the same severity or impact the user experience in the same way.

    That could seems pretty low considering how many people have had their hands in it "cleaning it up".

    I would be proud to be a part of that team. Let me just say GOOD JOB!
  • by rongage ( 237813 ) on Thursday September 07, 2006 @12:31PM (#16060102)

    I thought I would put my $.01 cents into the pool here - having recently been through something like this.

    Background: I am the author of some fairly unique software tools that allow you to communicate with industrial Programmable Logic Controllers. I consider the tools I write to be libraries with some example code showing how to use the library. It's all fairly simple stuff but one of my packages does a crapload of mallocs as it reads objects from the controller - basically it mallocs a data struct for every object, and then it also mallocs the data store for each object based on the data type (byte size) and how many items there are (3 dimensional array). In other words, a huge number of mallocs with no associated free statements.

    So one day I get an email from a guy who was interested in using my software but wanted to know when I was going to remove all the memory leaks from my code. He was kind enough to include a valgrind report that showed a huge number of memory allocations that were never freed. It took me forever to explain to the guy that while I could "eliminate those memory leaks", it would also destroy the value of the library as it would in effect delete all the data read out of the controller.

    Moral of the story: bug reports (including things like these code checkers and memory analysis programs like valgrind) are nice, but they need to be properly applied to be useful. Otherwise, these reports can be a significant distraction.

  • IANAP but I think that 71 vulnerabilities in a FULL FEATURED web browser product is absolutely amazing. Just imagine if there was a chance to audit the source for IE? How many vulnerabilities do you think there would be, considering there are so many found without even LOOKING at the actual codebase?
  • ...I can say that I am glad it is being run on something like Firefox.
    I just wish there was something similar I could run on my own code (or that others could run on their code), anyone aware of something similar?
  • I have this image in my head of an IE developer reading this story and thinking "Gee Slashdot, I guess writing a browser is pretty fucking hard, isn't it?"
  • "What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?"

    No we prefer to be ignorant of the problems in software we write, we prefer to assume everything is perfect.

    OF COURSE people prefer indepth analysis. I'm sure someone was like "damm it" when they got the report because they thought their code was flawproof but with the whole world as a consumer, people want to know what they can fix and make better, especially firefox who's core idea is create a browser that
  • by melted ( 227442 ) on Thursday September 07, 2006 @12:47PM (#16060228) Homepage
    The more they find, the more they fix, the more secure Firefox becomes. That's the beauty of open source for you, folks. For IE you wouldn't even know about half the bugs and vulnerabilities (which doesn't mean hackers wouldn't know about them, though).
  • by eno2001 ( 527078 ) on Thursday September 07, 2006 @01:14PM (#16060439) Homepage Journal
    Does the open source community that surrounds Firefox welcome this kind of analysis? I would have to say that's a RESOUNDING YES! As long as the analysis is truthful and reflects real problems that will improve the quality of Firefox I see no reason they wouldn't. Even pointing at minor issues will only help aid Firefox's improvement since it would give the developers a chance to see what people might really care about. And you can bet that if similar analysis was done of Internet Explorer that we'd find the same if not more defects and vulnerabilities. So this is NOT about Firefox vs. IE before anyone goes down that road.
  • by pherthyl ( 445706 ) on Thursday September 07, 2006 @01:16PM (#16060455)
    Of course they welcome this. Just look at the results page for the Coverty scans and see how many defects have been fixed in major open source projects. []
  • Firefox is the most unstable program in common use []. Some of the most serious bugs, like the CPU hogging bug, are more than 4 years old. So it's great that the Firefox team is getting some help. They need it.

    (Note that the main bug report linked is always marked invalid. That's not because anything has been done about the instability of Firefox; it's because people on the Firefox team don't want to, or don't know how to, fix the very, very serious bugs. Note also the links to magazine articles about Firefox instability, and the many links to user reports of problems.)

    I'm posting this comment from Firefox version It is using 22 percent of the CPU, even though all pages have been loaded, and there is no active content. That's 22% on the way to 70% or more, which will soon make it necessary to close all windows and tabs of Firefox and reboot Windows XP. (Firefox corrupts Windows XP SP2 with all patches applied, so that it is necessary to restart the OS. In Linux, it is necessary only to kill Firefox to get full control again.)

    The CPU hogging bug in Firefox runs the fan in a laptop computer continuously, meaning that expensive hardware maintenance will be required more often for heavy Firefox users.

    Firefox has extensions, but they often make Firefox unstable. The Firefox team thinks that it is entirely acceptable to market Firefox extensions, but when the extensions cause Firefox to be unstable, to excuse the instability by saying that it is caused by an extension.

    The version of Firefox was quite stable, if the Flashblock extension was installed. The version is unstable again.

    The problem appears to be that Firefox does not allocate enough resources. If you open several Firefox windows and several tabs in each window, and leave them open for several days, or suspend or hibernate your computer a few times, you will find that Firefox has started to hog the CPU.

    It is interesting to note that, when the latest version of Firefox is used with the latest version of Thunderbird, they both have trouble with the CPU hogging bug. The each corrupt the other. Weird, and seemingly a good clue to the flaw that causes CPU hogging.

    Apparently everyone on the Firefox team wants to add features or work on easy bugs. Apparently also, browser programmers are not necessarily heavy browser users. People who often do research on the internet, and open several Firefox windows and many tabs, and leave them open for several days, are certain or almost certain to cause Firefox to become unstable, however.

    Mozilla Foundation Top 14 Excuses for Not Fixing Bugs

    Top 14 things Firefox and Mozilla developers say about those who report difficult bugs, collected during the last 4 years:
    1. Maybe this bug is fixed in the nightly build.
    2. Yes, this bug exists, but other things are more important.
    3. No one has posted a TalkBack report. [If they had read the bug report, they would know that there is never a TalkBack report, because the bug crashes TalkBack, too, or a TalkBack report is not generated.]
    4. If you would just give us more information, we would fix this bug.
    5. This bug report is a composite of other bugs, so this bug report is invalid. [The other bugs aren't specified.]
    6. You are using Firefox in a way that would crash any software. [But the same use does not crash any version of Opera.]
    7. I don't like the way you worded your bug report. [So, I didn't read it or think about it.]
    8. You should run a debugger and find what causes this problem yourself. [Then when you have done most of the work, tell us what causes the problem, and we may fix it.]
    9. Many bugs that are filed aren't important to 99.99% of the users.
    10. If you are saying bad things about Mozilla and Firefox, you must be trolling. [They say this even though Firefox and Mozilla instabili
  • by cliffwoolley ( 506733 ) on Thursday September 07, 2006 @03:01PM (#16061262)
    Yes, as long as the analysis provides real, useful information.

    I've seen cases before where security companies have discovered big piles of "vulnerabilities" in certain other high-profile open source products. The problem in those cases that made the "vulnerabilities" not entirely welcome "discoveries" was that really the security company had just run their automated code analysis product over the OSS codebase and dumped the results on the OSS community without looking over them first to weed out the sometimes large numbers of false positives. The security companies in those instances, presumably, were more interested in promoting their own security product ("look at all these vulnerabilities our product found!") than in truly enhancing the OSS product being examined.
  • by aCapitalist ( 552761 ) on Thursday September 07, 2006 @03:44PM (#16061592)
    What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?

    First we have the obligatory borg-like, "the community" reference. But the question should be re-phrased to "How many of you are so emotionally immature and insecure that you'll throw a tantrum because there might be something not uber-positive said about Firefox, Linux, Gnome, KDE...?"

    P.S. who is making these thought decisions for "the community"?

"Let every man teach his son, teach his daughter, that labor is honorable." -- Robert G. Ingersoll