Mozilla: For the Record

Yesterday, Mozilla announced that one of the community built add-ons hosted by Mozilla contained remnants from a virus called W32/Xorer.A, also known as W32/Fujacks!htm.

After reading several dozen articles and blog posts covering that announcement, I thought I’d post a short a follow-up here in response to a few of the misunderstandings that I came across in some of those articles and blogs.

• The Vietnamese language pack add-on contained a worm or virus

  Headlines, by necessity, need to be short and to the point, but with security reporting, over-simplification can actually mis-inform readers.

  Despite what many of the headlines suggested, the compromised add-on did not contain a worm or virus. There was a virus on the developer’s computer. That virus inserted a small website-fetching script into the add-on. That script was not capable of replicating or spreading itself like a virus or a worm. It was simply telling Firefox to load unrequested advertisements. Disabling the add-on is an effective remedy for the problem script precisely because it is not a worm or virus.

• All or most Firefox users are affected because Firefox ships with support for all languages built in

  This is not correct. Some computer programs that work in multiple languages contain all of the translations in a single version. That isn’t the case for Firefox. Mozilla ships a distinct Firefox version for each of the 45 supported languages. Vietnamese is not one of those supported languages yet so Firefox users who want a Vietnamese translation must seek out and install this Vietnamese language pack add-on. Only users who installed that compromised Vietnamese language pack were exposed.

• 16,667 Vietnamese language pack users were affected

  While we don’t know what the exact number of affected users is, it is certainly less than that. The announcement mentioned that there have been 16,667 downloads of this add-on since November of 2007. That’s correct, but not all of those downloads were of the compromised version. The add-on was updated on February 18, 2008 and only those users who downloaded the February update of the add-on on were exposed.

• Firefox users should uninstall Firefox and run their AV software to clean up the problem.

  Because this isn’t a virus or a trojan, and it’s isolated to the Vietnamese language pack add-on, users do not need to uninstall Firefox or use third-party software to stop it. All they need to do is open the Add-ons Manager from the Tools menu and then select and disable the Vietnamese language pack.

• Mozilla systems had a virus or worm on them

  The virus was on the machine belonging to the add-on developer. The computers that produce and distribute Firefox were not exposed and were not responsible for the compromised add-on.

• Mozilla suspected the add-on author of malice

  Absolutely not. At no time did Mozilla suspect this and there is no reason to suspect or believe this.

• Add-ons cannot be trusted

  We scan all add-ons for viruses when they are uploaded to the Mozilla Add-ons website. This particular add-on contained the remnants of a virus that was still unknown to the anti-virus software performing that scan. As a result of this incident, we’re implementing additional vulnerability scans at regular intervals after an add-on has been uploaded to help mitigate similar problems going forward.

Add-ons provide a lot of value to a lot of Firefox users. We believe in that flexibility and power so we’ve invested heavily in infrastructure to host and support them and the amazing community that’s built them. Security is a key component of that investment and we take it very seriously when security issues come up with add-ons. Fortunately, this issue only affected a relatively small number of users, the impact to those users was not catastrophic, and the remedy was a simple three-click operation.

Going forward, we’ve got a better virus scanning solution in place and we’re looking into other ways to further insure the integrity and safety of all add-ons, not just those hosted by Mozilla.

More Reading:
Mozilla Security Blog » Compromised file in Vietnamese Language Pack for Firefox 2 by Window Snyder

Around the Web:
PC World » Firefox Plug-In Shipped With Malicious Code by Robert McMillan,   InternetNews: The Blog » Don’t Run Mozilla Firefox in Hanoi by Sean Michael Kerner,   Security Focus » Vietnamese pack infects Firefox users by Robert Lemos,   SC Magazine US » Compromised file found in language pack for Firefox by Chuck Miller,   Computerworld » Mozilla shipped worm with Firefox add-on by Gregg Keizer,   heise Security UK » Firefox add-on contains malware by Mike Barwise,   The Register » Firefox language pack provides adware back-door by John Leyden,   PCMag - Security Watch » Vietnamese Firefox Distribution Carried Malware by Larry Seltzer,   Wired.com - Threat Level » Firefox Infects Vietnamese Users With Trojan Code by Ryan Singel,   ZDNet.com - Hardware 2.0 » Mozilla spreads malware rather than security by Adrian Kingsley-Hughes,   Mozilla Links » Firefox Vietnamese language pack compromised by Percy Cabello,   CyberNet News » Big Oops: Mozilla Releases Compromised Vietnamese Language Pack by Ryan Wagner,   BetaNews » Vietnamese Firefox 2 users were given malicious content by Scott M. Fulton, III,   Mashable » Mozilla: Would You Like a Virus With That Add-on? by Stan Schroeder,   The Inquisitr » Viruses Hit Mozilla, MP3s by JR Raphael,   FavBrowser » Firefox Security? Here We Go Again by Vygantas Lipskas,   Donna’s SecurityFlash » Compromised file in Vietnamese Language Pack for Firefox 2 by Donna Buenaventura,   On Computers Tips » Firefox Infects Vietnamese Users With Trojan Code by Jack Imsdahl ,   Infosecurity.US » Firefox’s Vietnamese Language Pack Reportedley Infected with Trojan by Marc Handelman,   SANS Internet Storm Center » Compromised File In Vietnamese Language Pack For Firefox 2 by Joel Esler,   CyberInsecure.com » Adware Back-door In Firefox Language Pack,   Dantravels » Annoying Journalism from Robert McMillan, IDG News Service by Daniel Butler,   The Good Soldier LMeyerov » Social Software by Leo Meyerovich,   Tech-Ex » Firefox Language Pack Ships with Malware by Michael Santo,   Spyware Sucks » Alert: Firefox 2 Vietnamese Language Pack infected by malware by Sandi Hardmeier,   PortalIT News » Mozilla Warns: Firefox 2 Vietnamese Pack Features Trojan,   IT Business Edge - Headline Watch » Mozilla’s Vietnamese Plug-In Infected with Malware by Susan Hall,   McAfee Avert Labs Blog » Computer Security Research by Vinoo Thomas,   ReadersZone » Firefox Vietnamese Language Pack infected with Trojan horse by Ajay Pathak,   OpTempo » Firefox Vietnamese Language Pack Malware Warning by J. Frank Carr,   Byzone » Firefox AddOn Comes with Adware by FyreVortex,   Steve: Developing on the Edge » Virus in a firefox language plugin: the perils of the community by Steve Loughran

A number of press articles surrounding Symantec’s Internet Security Threat Report, and other recent similar reports from Cenzic and Secunia, are offering the confusing and incorrect conclusion that the effective security and safety of web browsers can be measured by simply counting the number of vendor disclosed software flaws.

At Mozilla, we’re concerned that this flawed measure of security does a disservice to users trying to navigate the already tricky Web security landscape.

This kind of measuring is flawed for several reasons, all related in that they make it more difficult for consumers to make informed decisions about their online safety.

First, for complex programs like Web browsers, the number of vulnerabilities identified is often more influenced by things like who is looking, and how good they are at finding security issues, than the number of vulnerabilities actually present in the software.

Second, not all security flaws have the same impact on user safety. Comparing flaws which could allow arbitrary code execution to denial of service susceptibility doesn’t really provide users with actionable information.

Third, different organizations have different disclosure policies so a reporter or a user cannot get useful information by comparing the bug counts for products from different vendors.

And this is actually the fatal flaw of this kind of bug counting. When you count Mozilla security bugs you are seeing not just those flaws found and reported by third-party security researchers, but also the ones discovered and reported by Mozilla people — bugs that would be considered internal and probably never disclosed if we acted like most other software vendors.

That’s simply not the way other browser vendors disclose flaws. For those vendors, only flaws discovered by outside security researchers are disclosed, under pressure from the security researchers who would go public if the vendor did not. Internally found flaws are fixed and deployed, often in long delayed service packs, without the same disclosure.

This makes comparing the counts for those vendors and the counts available from Mozilla a true apples and oranges situation.

All of that brings up the very legitimate question, how should security be measured and how can people use better measures to make better choices.

For more than a year, Mozilla, along with members of the broader security community and some in the security tech press, has been advocating for measures of security that are both simple to digest, and much more useful to people trying to make secure technology decisions.

One measure we’ve settled on is called “Window of Exposure” and it is measured as the difference in days between the time at which exploit code affecting a vulnerability is made public and the time at which the affected vendor makes a patch available to the public for that vulnerability.

A variant of this measure is included in the Symantec report. This is great, but unfortunately it’s buried late in the report. Because simple bug counting is so much easier to explain, the better measure often gets left out of press accounts entirely.

A second measure is is called “Time to Deploy”. Time to Deploy is how long it takes for users to get a patch installed once the fix is available from the vendor. Just because it’s fixed, doesn’t mean that users all have the fix, leaving them vulnerable. The most important factor in minimizing Time to Deploy is the efficacy of the vendor’s automatic update system.

These two combined measures describe in fairly simple terms the number of days that a particular vendor’s users are vulnerable to security threats that result from software flaws. It’s our hope that more people will adopt these measures and that as a result, users will be able to make much more informed technology decisions.

So, we’d encourage Symantec to shift the emphasis to the more meaningful metric they already report, to begin measuring and reporting on Time to Deploy, and to and stop using the flawed apples to oranges bug count altogether.

And one final note: There are a lot of web browser advocates who will jump on any new report that compares browser security as an opportunity to promote their favorite. This happens all over the Web, and certainly within the Mozilla community and the communities of the other popular browsers.

Members of the Mozilla community are encouraged, when talking about browser security, to push back against meaningless bug counts, even when those counts would favor Mozilla. Instead, they should focus on measures that truly reflect how safe the browsers are, like the aforementioned “Window of Exposure” and “Time to Deploy.”

More reading
Mozilla Developer News » Better Metrics for Security - Understanding the Symantec Internet Security Threat Report
Mozilla Security Blog » Read past the headlines - Firefox is fixed faster
Mozilla Security Blog » Time to Deploy improvement of 25 percent
Mozilla Security Blog » Critical Vulnerability in Microsoft Metrics

Around the Web

Symantec Internet Security Threat Report:
Symantec Corporation » Internet Security Threat Report,    Symantec Corporation » Internet Security Threat Report Volume XIII: April, 2008 (PDF),    Mozilla Links » Handle with care: Symantec on web browsers security,    Ars Technica » Report: Microsoft fastest to issue OS patches, Sun slowest,    CIO » Report: ActiveX, QuickTime are buggiest browser plug-ins,    Times Online » Number of computer viruses tops one million,    ReadersZone » Most Insecure Browser Mozilla Firefox,    CNET News.com’ One More Thing » Mac security not so much about the Mac,    Builder AU News » Malware writers now number one software makers,    Softpedia » Browser Wars: Internet Explorer vs. Firefox. vs. Safari vs. Opera - Vs. vulnerabilities in 2007,    ComputerWorld - Security » Research fingers ActiveX, QuickTime as buggiest browser plug-ins

Cenzic Application Security Trend Report:
Cenzic » Application Security Trend Report Highlights 2007 as Another Crisis Year for Web Security,    InfoWorld’s Security Watch » Pervasive Web apps flaws under siege,    Redmond Developer News » Study: The Year’s Top-10 Web Application Vulnerabilities,    Softpedia » Is Internet Explorer Safer Than Firefox, Opera and Safari? - Just because it has less security vulnerabilities?,    Secure Web » 2007 - Another crisis year for Web Security!,    Windows Vista Magazine » Internet Explorer 7 the safest browser ever,    Help Net Security (HNS) » Microsoft Internet Explorer least vulnerable browser in Q4

Secunia and Microsoft’s Jeff Jones’ Internet Explorer and Firefox Vulnerability Analysis:
Jeff Jones Security Blog » Internet Explorer and Firefox Vulnerability Analysis,    PC World » Red Hat and Firefox More Buggy Than Microsoft Apps,    coldtobi’s blog » Apples and Oranges, Firefox and Internet-Explorer,    Ars Technica » Mozilla scoffs at vulnerability study rating IE superior to Firefox,    ComputerWorld » Microsoft, Mozilla trade punches over browser security,    InfoWorld » Vulnerability counts do matter

Other:
Mark J Cox » Transparency,    EWeek » Microsoft Patches: When Silence Isn’t Golden

Last week, a number of articles and blog posts noted that we had added another Firefox Beta (the 4th) to our schedule. Most of the Beta 4 mentions were made in articles and posts that were more heavily focused on the upcoming release of Beta 3 but several did investigate (or at least speculate) and report on the reasons for the addition of Beta 4 to the Firefox schedule.

As several of the linked posts below accurately reported, we’ve decided to add one more beta in order to make further improvements in the areas of polish, performance, memory, and overall quality. That does beg the question, how does Mozilla decide when to stick to the prior schedule and when to adjust the schedule. That’s what motivates this post.

The Mozilla product cycle is actually quite a bit different from those of most software producers. I’ve asked Mike Beltzner, the man driving the Firefox 3 release, to help explain some of the differences and how those differences informed the decision about adding a fourth beta to the schedule.

The first and most important thing to state is that we, as a project, are quality driven, not date driven. We use dates to set targets for milestones, and we strive to put out the best milestones possible, but due to the changing nature of the web, we always judge each milestone against our basic criteria of quality, performance and usability. The other factor how we rely on community use and testing of our betas to help us judge their quality. Without our close-to-million strong beta audience, we couldn’t get the usage and testing data required to provide us with the confidence to move into a shippable product.

In the context of adding a fourth beta, the decision was between holding beta 3 for some new work being done on performance, usability, and memory use, versus shipping the beta sooner to get testing on the improvements (based on community feedback) from the past month and a half. We decided that the best thing for our beta audience would be to release beta 3 and add another milestone as opposed to holding for the late-braking improvement opportunities. Those will be the basis for our fourth beta.

We all want to ship the best browser possible on the fastest timescale, and we meet weekly to evaluate our current product against the potential improvements we could continue to make. When our quality, usability and performance are solid enough to be called Firefox 3 (as judged by everyone involved in making it) we’ll ship it.

Often times folks in the Mozilla community, when asked when the next version will be available, use the short-hand “When it’s ready.” If you’re looking for a more precise description for “When it’s ready”, feel free to quote Beltzner or to reference this article.

More reading:  
Mozilla Developer News » Firefox 3 beta 3 code freeze tonight, and
Mozilla Wiki » Firefox3/StatusMeetings/2008-01-29

Around the Web:   ZDNet.com » Getting closer: Firefox 3 Beta 3…,   ComputerWorld » Mozilla freezes Firefox 3.0 Beta 3,   InternetNews » Firefox 3 Beta 4?,   CyberNet » Firefox 3 Beta 3 Coming with a Big New Feature,   Softpedia » Firefox 3.0 Beta 4 Confirmed…,   Download Squad » Mozilla updates Firefox…,   Gadgetell » Firefox 3.0 Beta 4 expected shortly,   D’Technology Weblog » Firefox 3.0 Beta 4 confirmed,   The OpenSourceDeal Blog » Firefox 3 update,   Communication Technology » Firefox 3,   Technology Basement » Firefox 3.0 Beta 4 up in the Air…,   Krishna Srinivasan’s Blog » Firefox 3 Beta 3 to be out Feb 11,   Gadgets Control » Firefox 3.0 Beta 4 expected shortly,   iloog » Firefox 3 B3 completed at least will have a Beta,   Just Thinkin’ » Firefox 3 Beta 3 Update,   Security Watch » Firefox Updates Imminent,   Electronista » Mozilla locks Firefox 3.0 Beta 3

Welcome to the new For the Record blog.

For the Record is a Mozilla community program for discovering, cataloging, and responding to what’s being said about Mozilla online.

We also want to make it easier for people to talk/report/blog about Mozilla by providing a collection of answers to frequently asked questions and responses to common misconceptions or mistakes.

As we go forward, this program will also help develop spokespeople who will be able to deliver the Mozilla story more effectively and in more places.