Slashdot Log In
611 Defects, 71 Vulnerabilities Found In Firefox
Posted by
kdawson
on Thu Sep 07, 2006 10:50 AM
from the rolling-in-bugs dept.
from the rolling-in-bugs dept.
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 1.5.0.6. 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.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Obvious. (Score:5, Insightful)
Obviously, yes. Otherwise, open source would be closed-source.
Re:Obvious. (Score:5, Interesting)
Parent
Re:Obvious. (Score:4, Funny)
Like the kid that was goth before it was popular, it's time to change to a more obscure web browser.
Parent
Re:Obvious. (Score:5, Funny)
MSIE 3.0 here I come!
Parent
Re:Obvious. (Score:5, Informative)
Parent
Opera easily countable using useragent string (Score:5, Informative)
Parent
Speaking of which... (Was Re:Obvious.) (Score:5, Insightful)
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.
Parent
Re:Speaking of which... (Was Re:Obvious.) (Score:5, Interesting)
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.
Parent
Re:Speaking of which... (Was Re:Obvious.) (Score:5, Insightful)
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.)
Parent
Re: (Score:3, Insightful)
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.
Firefox Top 15 Excuses for Not Fixing Bugs (Score:5, Insightful)
Mozilla Foundation Top 15 Excuses for Not Fixing Bugs
Top 15 things Firefox and Mozilla developers say about those who report difficult bugs, collected during the last 4 years:
Parent
That oo.org bug is horrifying. (Score:5, Insightful)
Paraphrasing:
User: If you use the KDE save dialog, oo.org doesn't check before clobbering your files. Here's a simple three-line method to reproduce a bug that can cause users to lose data.
Developer: Works for me if I use the GTK or oo.org dialogs. *closes bug*
User: I said the *KDE* dialogs.
Developer: But oo.org uses its own dialogs. That's KDE's problem. *closes bug*
User: There's an option for using native dialogs! Right here! Also, no other KDE app has this problem. You're not using the filepicker correctly.
User 2: I can confirm this. Something's definitely up with the code interfacing with KDE's filepicker.
[five months pass]
Developer 2: Have you tried a newer version? Maybe it's fixed in the point release. Re-open if you're still having the problem. *closes bug*
I have to laugh, to keep from crying.
Parent
Try a new profile (Score:4, Informative)
I don't think developers tell you to try the standard diagnostic. That's what end-users wrote in the MozillaZine Knowledge Base.
Developers will ask you if the problem happens with a new profile. If it doesn't, that means something different in the original profile triggers the problem. If someone can discover what that difference is, then the bug in Firefox can be found and fixed. It's not an excuse to avoid fixing a problem. It's troubleshooting what the problem is so it can be fixed.
Parent
Security reviews are _the_ push for OSS (Score:5, Insightful)
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.
Parent
Re:Obvious. (Score:5, Funny)
Parent
Memory leaks (Score:5, Interesting)
Re:Memory leaks (Score:5, Insightful)
Parent
Re: (Score:3, Interesting)
Re:Memory leaks (Score:5, Funny)
God-damned copy and pasta bug!!!
What, is it giving you spaghetti when you wanted ravioli?
Parent
Re:Memory leaks (Score:5, Funny)
It's what he gets for using a pirated version of Firefox!
Parent
Another soul (Score:5, Funny)
Parent
YES! (Score:5, Insightful)
God I hope so. What on earth is the advantage of open source security if they don't get this kind of analysis?
TW
Why Not? (Score:5, Insightful)
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: 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)
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)
Parent
Re:Why Not? (Score:5, Insightful)
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.
Parent
Re:Why Not? (Score:4, Interesting)
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.
Regards,
--
*Art
Parent
Re:Why Not? (Score:4, Insightful)
"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.
Parent
Re:Why Not? (Score:4, Interesting)
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.
Parent
Why not? (Score:5, Insightful)
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.
Cheers
I value it (Score:4, Interesting)
Answer: (Score:5, Funny)
No, they're going to sweep this under the rug and disappear anyone else who audits their code. What the fuck do you think?
Of course it does (Score:5, Insightful)
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)
Costs and motivations (Score:5, Insightful)
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.
Copy, paste (Score:5, Funny)
Re:Copy, paste (Score:4, Funny)
Hey, if it makes them fix the copy/paste bug, it's all good by me.
Parent
One would certainly hope so... (Score:5, Interesting)
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 [sf.net] 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.
Tools like this produce lots of false positives (Score:5, Informative)
I kid you not... (Score:5, Funny)
Not too bad (Score:4, Insightful)
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.
Full disclosure is the way to go (Score:3, Insightful)
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.
which one of those bugs was the (Score:5, Funny)
Yeah, that's right. I just admitted to using Myspace for more than 20 minutes at a time.
Re:which one of those bugs was the (Score:5, Funny)
Parent
For one who works in QA this doesnt bother me.... (Score:4, Insightful)
Coverity already did a scan (Score:4, Informative)
Disable-Output-Escaping (Score:4, Interesting)
http://bugzilla.mozilla.org/show_bug.cgi?id=98168 [mozilla.org]
Do they welcome this? (Score:4, Interesting)
http://scan.coverity.com/ [coverity.com]
The Firefox team needs the help. (Score:5, Interesting)
(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 1.5.0.6. 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 1.5.0.4 version of Firefox was quite stable, if the Flashblock extension was installed. The 1.5.0.6 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:
Welcome this kind of analysis (Score:4, Insightful)
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"?
Re: (Score:3, Informative)
It sounds like the majority of the bugs were not checking if a memory allocation failed (e.g. new returned null). In the era of seemingly limitless virtual memory -- not to mention that a failure to acquire memory is usually unrecoverable anyways -- that's (unfortunately) a completely normal development practice. Those are pretty much irrelevant bugs.