I have seen many people complaining about how Firefox is no more secure than Internet Explorer. Usually this impression comes up when people read the long lists of security bugs fixed with every maintenance release. Since I have reported a few security bugs myself and could observe how Mozilla deals with those, I knew well that Firefox is still incomparably more secure than Internet Explorer — and now there is proof. Internet Explorer Unsafe for 284 Days in 2006 has the data. Last year users of Internet Explorer have been exposed to unpatched critical security flaws for 284 days in total, on 98 of those days the security flaws were actively abused by web sites. In comparison, there was only one vulnerability in Firefox that was publicly disclosed before a patched Firefox release was available, amounting to 9 days of exposure.
So where did the long lists of security bugs go? Did the author of this article overlook them? No, he didn’t. These bugs were there, they have been discovered and fixed — and only then the information on them has been disclosed. So while each and every software has bugs, the major difference here is that Firefox vulnerabilities are reported and fixed before the information is disclosed and somebody gets a chance of abusing them — and with Internet Explorer it often happens the other way round.
What makes security researchers disclose information on IE vulnerabilities before those are fixed? As far as I can tell, it is not because they hate Microsoft. It is simply that reporting security issues to Microsoft is so painful. Microsoft tends to downplay the severity of the issues or call them a “feature” (e.g. the clipboard access bug that has been first reported in 2002 and is still unpatched). Security issues are also given low priority so that it may take a year until the actual fix. So far the best way to make Microsoft recognize the real severity of the bug and react was to disclose all information, ideally together with source code of the exploit.
On the other hand, Mozilla has a policy of treating every security issue as severe unless proven otherwise. With some luck the hole is patched within hours after it has been reported, so far I haven’t seen anything taking more than a week unless it is really very uncritical and hard to fix. Security issues are always top priority and they are never downplayed. And Mozilla always discloses all information on the fixed bugs so that people using old versions know the risks, never are security issues swept under the carpet (as happened to at least some Internet Explorer vulnerabilities discovered by Microsoft employees).
Good afternoon. I have just purchased norton’s 2007 version of the stand alone internet security & System Works. I haven’t tried Firefox yet but IE is running much faster now, and i expect that Mozilla will, also. Minimized DL, common sense, and Search and Destroy used often, means that using IE doesn’t scare me enough to stop using it. I use Firefox because I like the sage feedreader and other add-ons.
A firewall is essential to protect your computer but it is insufficient when it comes to browser bugs. It can detect patterns of known exploits but when all information about a security hole is disclosed anybody could relatively easily create a different exploit that won’t be detected by the firewall. So while having a firewall and an antivirus is always a good thing, it doesn’t save you the hassle of installing a secure browser.
“With some luck the hole is patched within hours after it has been reported, so far I haven’t seen anything taking more than a week unless it is really very uncritical and hard to fix.”
On the same page that you link to about Firefox vulnerabilities, you’ll find the following data.
Firefox 188.8.131.52, released on December 19, 2006, fixed many critical issues, including this one.
Security Advisory 2006-68 – “...we presume that at least some of these could be exploited to run arbitrary code with enough effort.” One bug reported January 4, 2006. Time to fix: nearly a year. Another bug reported April 21, 2006. Time to fix: eight months.
Firefox 184.108.40.206, released September 14, 2006:
Security Advisory 2006-64 – “Some of these were crashes that showed evidence of memory corruption and we presume that at least some of these could be exploited to run arbitrary code with enough effort.” Reported September 3, 2005. Time to fix: over a year.
Firefox 220.127.116.11, released July 27, 2006 fixed this critical bug, among others:
Security Advisory 2006-55 – “Some of these crashes showed evidence of memory corruption that we presume could be exploited to run arbitrary code with enough effort.” Reported April 1, 2005. Time to fix: one year and about four months.
So now you have seen critical bugs in Firefox – exploitable bugs – that have taken more than a year to fix after they were reported.
I never said that Mozilla didn’t prioritize the bugs. Looking at a few of these crash reports – they seem pretty harmless. The probability that any of those are exploitable is very low. Given that some of them were pretty non-trivial, it is not surprising that it took long to fix them. IMO the reason these crashes got a high severity rating is only their number – if somebody digs in those crashes long enough, he probably will find one that can be exploited. And that’s exactly what the security advisories are saying.
You have to keep in mind that these cases are not uncommon. In a complex program like a browser there are always less used code paths that will crash on unusual input, often also corrupting memory. That’s not a problem specific to Mozilla, Internet Explorer’s drag&drop implementation for example is known to be crash-friendly – and these crashes haven’t been fixed in years. This doesn’t have any consequence for the users, they are very unlikely to ever hit these crashes – but once somebody really puts enough effort into it, he might find a way to exploit these bugs and then they will become a huge problem.
Hmm… But you said, “I haven’t seen anything taking more than a week unless it is really very uncritical and hard to fix.” And I pointed out Firefox vulnerabilities rated by Mozilla as Critical that took over a year to fix.
You called the vulnerabilities “pretty harmless.” Maybe you have differing views of what Critical means compared to Mozilla? They said they are probably remotely exploitable code execution vulnerabilities.
So, would you say that you have seen critical vulnerabilities that took Firefox more than a week to fix, or that Mozilla improperly called them Critical?
As I said – each of those crashes for itself is pretty harmless, nothing unusual. But if you take a larger number of them together there probably will be one or two where an exploit possibility has been overlooked. Of course Mozilla could do a thorough investigation of every crashing bug but that would be a waste of resources, nothing is gained by that. It is safer to give these bugs a “Severe” rating even though you can’t really pinpoint it to a single bug. Once again, there is no vulnerability that received a “Severe” rating – only a possibility that one might be there, one amongst a dozen harmless bugs.
I was talking about bugs where there is at least some reasonable suspicion that they can be exploited (see for example bug 257431 that didn’t even get on the list of vulnerabilities – note that the general solution discussed there has been implemented and bugs like this one cannot happen any more).
“So, would you say that you have seen critical vulnerabilities that took Firefox more than a week to fix, or that Mozilla improperly called them Critical?”
Perhaps it is because in fact they were not Critical SECURITY vulnerabilities, but instead were Critical Application Faults that caused application crashes. I can see that the Critical is still there, but the Vulnerability has gone away.
Thanks for the response. You wrote, “Perhaps it is because in fact they were not Critical SECURITY vulnerabilities…”
But in my original post, I was quoting from the original Firefox security vulnerabilities:
Security Advisory 2006-68 – “...we presume that at least some of these could be exploited to run arbitrary code with enough effort.”
Security Advisory 2006-64 – “...we presume that at least some of these could be exploited to run arbitrary code with enough effort.”
Security Advisory 2006-55 – “...we presume could be exploited to run arbitrary code with enough effort.”
And just so we don’t lose track of my original point, I pointed out that the last one I quoted took about a year and four months to fix.
Thanks for discussing this with me, Wladimir.
Unfortunately, when you say, “each of those crashes for itself is pretty harmless” in response to bugs that Mozilla describes as, “crashes with evidence of memory corruption“ I just can’t agree with you. Perhaps there is a fundamental difference in our mutual vocabulary.
Anyway, thanks again for the discussion.
Memory corruption is only a security problem if the website can control what is written into memory – which is rarely the case. Buffer overflows are the ones that are almost always security issues.
see also: BrowseHappy.com/why
... security at the cost of window focus stealing is getting to be too pricey
Its critical to not-annoy users.
Dan Veditz and I agree that several common types of crashes other than buffer overflows should be considered security holes by default. See these entries on my blog:
Determining whether a crash looks exploitable
Memory safety bugs in C++ code
Thanks, Jesse, I already read these posts. I probably wasn’t too clear in my previous response – I meant that buffer overflows are the ones that almost always can be exploited. Dangling pointers on the other hand are dangerous but I think that in most cases they cannot be exploited. Which isn’t saying that MoCo shouldn’t treat them as security issues of course.