611 Defects, 71 Vulnerabilities Found In Firefox

Obvious. by keyne9 · 2006-09-07 03:52 · Score: 5, Insightful

do Firefox and the open source community welcome this kind of analysis?

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

Re:Obvious. by ClamIAm · 2006-09-07 04:15 · Score: 3, Insightful

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.
Re:Obvious. by ztirffritz · 2006-09-07 04:19 · Score: 2, Insightful

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.

--
Why doesn't anything interesting happen when I have mod points?
Re:Obvious. by Irish_Samurai · 2006-09-07 04:55 · Score: 2, 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.

or

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

or

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.

YES! by Total_Wimp · 2006-09-07 03:53 · Score: 5, Insightful

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?

TW

Why Not? by eldavojohn · 2006-09-07 03:53 · Score: 5, Insightful

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!

--
My work here is dung.

Re:Why Not? by RAMMS+EIN · 2006-09-07 03:59 · Score: 4, Insightful

``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)

--
Please correct me if I got my facts wrong.
Re:Why Not? by Todd+Knarr · 2006-09-07 04:26 · Score: 3, 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.
Re:Why Not? by cheezit · 2006-09-07 04:40 · Score: 2, Insightful

"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 conventional code defect work to get to the same level of quality.

--
Premature optimization is the root of all evil
Re:Why Not? by ajs · 2006-09-07 04:55 · Score: 4, Insightful

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.

Why not? by gstoddart · 2006-09-07 03:54 · Score: 4, Insightful

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.

Of course it does by Dark+Paladin · 2006-09-07 03:55 · Score: 5, Insightful

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

Costs and motivations by kjs3 · 2006-09-07 03:57 · Score: 4, Insightful

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.

Speaking of which... (Was Re:Obvious.) by Billosaur · 2006-09-07 04:01 · 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.

--
GetOuttaMySpace - The Anti-Social Network

Re:Speaking of which... (Was Re:Obvious.) by ScrewMaster · 2006-09-07 05:32 · Score: 4, Insightful

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

--
The higher the technology, the sharper that two-edged sword.

Re:Memory leaks by kripkenstein · 2006-09-07 04:02 · Score: 4, Insightful

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?

Not too bad by dctoastman · 2006-09-07 04:03 · Score: 4, Insightful

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

Full disclosure is the way to go by bob+whoops · 2006-09-07 04:06 · Score: 2, 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.

For one who works in QA this doesnt bother me.... by Thrymm · 2006-09-07 04:16 · Score: 4, Insightful

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

bugs != exploits by no+reason+to+be+here · 2006-09-07 04:17 · Score: 2, Insightful

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

Security reviews are _the_ push for OSS by msobkow · 2006-09-07 04:22 · 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.

--
I do not fail; I succeed at finding out what does not work.

Re:Security reviews are _the_ push for OSS by ronanbear · 2006-09-07 04:34 · Score: 2, Insightful

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

--
the more they over-think the plumbing the easier it is to stop up the pipe
Re:Security reviews are _the_ push for OSS by msobkow · 2006-09-07 04:44 · Score: 2, Insightful

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.

--
I do not fail; I succeed at finding out what does not work.

Having recently been through this... by rongage · 2006-09-07 04:31 · Score: 2, Insightful

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

That's a GOOD thing by melted · 2006-09-07 04:47 · Score: 2, Insightful

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

Well... SWEET Begina!!! by eno2001 · 2006-09-07 05:14 · Score: 2, Insightful

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

Re:Memory leaks by supersnail · 2006-09-07 05:47 · Score: 2, Insightful

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 your
50 lines of code) is identifing real leaks in the mass of potential
leaks reported.

Fixing them all is not really an option as they report things like:--
Storage blocks you intend to use in other routines but you stored the
the address somewhere else.
Things you don't bother releasing because you are bailing out as
quickly as possible.
You have your free tucked inside a conditional as in:
if (lasttime == true) { freemem(stuff); }
You you use memalloc as a way of allocating what is essentially
static storage. e.g. You have "buffersize" set in a config file
and allocate the memory during intialisation and never free it.

If you try to get round this by coding extra freemems you just end
up with lots of "possable memory free twice" error messages.

C programers usally code a wrapper for malloc and freemem so they can
track these problems themselves.

--
Old COBOL programmers never die. They just code in C.

Firefox Top 15 Excuses for Not Fixing Bugs by Futurepower(R) · 2006-09-07 06:26 · Score: 4, Insightful

Firefox developers become "defensive" when so many users report problems? That's a new excuse for the collection:

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:

Maybe this bug is fixed in the nightly build.
Yes, this bug exists, but other things are more important.
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.]
If you would just give us more information, we would fix this bug.
This bug report is a composite of other bugs, so this bug report is invalid. [The other bugs aren't specified.]
You are using Firefox in a way that would crash any software. [But the same use does not crash any version of Opera.]
I don't like the way you worded your bug report. [So, I didn't read it or think about it.]
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.]
Many bugs that are filed aren't important to 99.99% of the users.
If you are saying bad things about Mozilla and Firefox, you must be trolling. [They say this even though Firefox and Mozilla instability is beginning to be reported in media such as Information Week. See the links to magazine articles in this Slashdot comment: Firefox is the most unstable program in common use.]
Your problem is probably caused by using extensions. [These are extensions advertised on the Firefox and Mozilla web site, and recommended.]
Your problem is probably caused by a corrupt profile.
If you are technically knowledgeable, you can spend several hours trying to discover the problem: Standard diagnostic - Firefox. [Firefox has "Standard Diagnostics"! LOL.]
I won't actually read the (many) bug reports, but I will give you some complicated technical speculation which pretends to be helpful but, on investigation, is shown to have nothing to do with the bugs.
It's understandable that Firefox developers become defensive when users report so many problems.

Re:Firefox Top 15 Excuses for Not Fixing Bugs by ebyrob · 2006-09-07 11:16 · Score: 2, Insightful

Perhaps the reality is that the primary difference between proprietary and OSS developers is that the former has to take full responsiblity for their work and the latter can pass the buck.

Na, buck-passing is an innate human trait. I don't think there's a software developer alive who hasn't done it. At least not an experienced one.

Re:They're not "irrelevant bugs". by ergo98 · 2006-09-07 06:38 · Score: 2, Insightful

What a stupid thing to say.

And remarkably I said a simple statement of fact that said nothing about whether it was a good idea or not.

Any web browser developer who thinks that making "adaptive" use of gobs if memory is a good idea is a complete moron. Any kind of substantial RAM based web cache is just a bad fucking idea.

What an incredibly stupid thing to say.

yes, as long as.... by cliffwoolley · 2006-09-07 07:01 · Score: 2, Insightful

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.

That oo.org bug is horrifying. by Grendel+Drago · 2006-09-07 07:20 · Score: 4, Insightful

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

Welcome this kind of analysis by aCapitalist · 2006-09-07 07:44 · Score: 3, Insightful

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

Most are glaring bugs that aren't being fixed.... by spinctrl · 2006-09-07 12:25 · Score: 2, Insightful

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

Re:You're a fool, Dennis Forbes. by ergo98 · 2006-09-07 13:18 · Score: 2, Insightful

You obviously have no experience with real-world software.

Way more than you.

A segfault caused by something as stupid as not checking the success of a memory allocation can be disasterous.

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.

They alert a system operator to the lack of memory, and the operator can remedy the problem (if possible), and then allow for the execution to continue from where it left off.

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.

blah blah blah...blah blah blah...blah blah blah

Maybe you should meet up with the real world some day.

I hope that you are not allowed to perform any programming tasks, as you obviously lack the skills necessary to develop software in a safe, secure manner.

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!

Slashdot Mirror

611 Defects, 71 Vulnerabilities Found In Firefox

35 of 434 comments (clear)