Slashdot Mirror
611 Defects, 71 Vulnerabilities Found In Firefox
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?
do Firefox and the open source community welcome this kind of analysis?
Obviously, yes. Otherwise, open source would be closed-source.
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.
God I hope so. What on earth is the advantage of open source security if they don't get this kind of analysis?
TW
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!
My work here is dung.
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.
Cheers
Lost at C:>. Found at C.
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.
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
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.
Insisting on "correct" English is like saying that there is only one, definitive recipe for chili.
Right after they hired that Microsoft Security expert nevertheless!
> 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?
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.
52 Weeks, 52 Religions with John Hummel
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.
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.
Hey, if it makes them fix the copy/paste bug, it's all good by me.
-----
...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.
The Army reading list
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.
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.
GetOuttaMySpace - The Anti-Social Network
Firefox just crashed while I was reading this article.
120 characters for a sig? That's bloody useless.
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.
My twitter
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.
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.
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.
"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.
Blessed be he who reads this post, Cursed be he who tells my boss.
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 (http://www.amazon.com/Art-Software-Testing-Second /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....
In your post, you conflate software bugs with security vulnerabilities. These two things are not equivalent; at best, security vulnerabilities are a subset of software bugs.
my pet machine
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.
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.
I do not fail; I succeed at finding out what does not work.
Well they certainly don't appreciate being reminded that they still don't support the disable-output-escaping feature of XSLT..
http://bugzilla.mozilla.org/show_bug.cgi?id=98168
..Jeff Keegan
seven syllables explain TiVo: kee gan dot org slash ti vo
Que the crickets...
After calming me down with some orange slices and some fetal spooning, E.T. revealed to me his singular purpose.
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).
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.
Ron Gage - Westland, MI
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).
Touched by His noodly appendage.
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.
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
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.
http://scan.coverity.com/
(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:
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:
And remarkably I said a simple statement of fact that said nothing about whether it was a good idea or not.
What an incredibly stupid thing to say.
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.
Oh. My. Pants. I saw that oo.org bug referred to in one of those posts that you link to.
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.
Laws do not persuade just because they threaten. --Seneca
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.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
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"?
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.
What a fool believes, he sees, no wise man has the power to reason away.
That FF is buggy is no big revelation. The fact that the source is open to peer review (an OSS advantage) and scrutiny means that there is hope. However, having tried Firefox 2.0b I've noticed it still suffers from chronic memory leaks -- which even seem to permeate into the X server. With a desktop uptime that's measured in months, although KDE does save session state, running such resource corrupting desktop apps isn't an option. I certainly cannot recommend FF to anyone with a PC with less than 1GB RAM, Windows or otherwise. Why consider FF when there better alternatives, such as Opera (closed) and Konqueror (open).
Way more than you.
What are we talking about again? Oh, right, a fucking web browser. Get some context you weirdo. Hyperbole appears to be your strong suit, however.
I'm sorry, did we start talking about mainframe programming? Oh, no, we didn't, nor are we talking about a banking application, or a database.
Down here in the real world -- you might want to visit some time -- the operating system raises warnings when memory gets low, and will start slogging slower and slower. Here's the funny thing: When memory is actually completely exhausted the system is basically hosed. I know I know -- it's us unprofessional people that are to blame. Or maybe...just maybe...operations actually desperately required that memory, causing a cascading fault that is unrecoverable.
Maybe you should meet up with the real world some day.
And I hope that pulsing vein throbbing away on your forehead, and your unjustified sense of righteousness, doesn't give you an early stroke. Maybe next time you're talking about a, ermm, fucking web browser you could keep just the smallest amount of perspective.
OMG! Firefox crashes along with the rest of the system, taking down the heart pump!