Clarification on Vietnamese Language Pack Compromise
May 12th, 2008
As today’s headlines confirm, there is still a lot of confusion about what happened to the Vietnamese language pack, who is impacted, and what that impact really is.
First of all, there is no virus in the Vietnamese language pack. Vietnamese language pack for Firefox users have not been infected with a virus. The remnant we detected is a line in an html file that would display ads to users. This does not infect the user’s machine with the virus. It is a remnant from a virus that most likely infected the language pack developer’s machine. This code remnant is not present in other language packs. The entire add-ons site has been scanned for malware and viruses and nothing else has been detected. Disabling the language pack in the add-ons dialog disables the code remnant.
Mozilla scans all add-ons for viruses at upload time, but the nature of most anti-virus software is that it only finds the things it knows how to look for. When this add-on was uploaded there was no signature in the anti-virus software to detect this virus or its remnants.
There have been 16,667 downloads of the Vietnamese language pack since November 2007. It is hard to identify exactly how many users were impacted, but there are on average about 1000 active users. While the number of users is small, this is still unacceptable. We take this issue very seriously. The most likely impact for users was the display of unwanted ads.
These are the steps we have taken to protect users in the future:
• The add-ons site was immediately scanned for the presence of viruses and other potential malware, and nothing further has been detected.
• As a response to this issue and to minimize the potential of something similar happening in the future, Mozilla is now scanning all add-ons whenever the signatures for the anti-virus software are updated.
Compromised file in Vietnamese Language Pack for Firefox 2
May 7th, 2008
The Vietnamese language pack for Firefox 2 contains inserted code to load remote content. This code is the result of a virus infection, but does not contain the virus itself. This usually results in the user seeing unwanted ads, but may be used for more malicious actions.
Everyone who downloaded the most recent Vietnamese language pack since February 18, 2008 got an infected copy. While we cannot determine the exact number of compromised downloads, there have been 16,667 total downloads of the Vietnamese language pack since November 2007, so we anticipate the impact on users to be limited.
Mozilla does virus scans at upload time but the virus scanner did not catch this issue until several months after the upload. We are also adding after-the-fact scans of everything to address this sort of case in the future.
A new language pack will be available shortly. Until then, Vietnamese language pack users should disable this package using the add-ons dialog on the Tools menu.
More information is available in bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=432406
Firefox 2.0.0.12 is now available
February 8th, 2008
Firefox 2.0.0.12 is now available. This security update addresses the directory traversal issue described here and here. Details for this release are available at: http://www.mozilla.org/projects/security/known-vulnerabilities.html#firefox2.0.0.12
Status update for Chrome Protocol Directory Traversal issue
January 29th, 2008
Background on this issue is available here.
Impact
An attacker can use this vulnerability to collect session information, including session cookies and session history. Firefox is not vulnerable by default. Only users that have installed “flat” packed add-ons are at risk. Discussion about “flat” packaged add-ons is here. A partial list of “flat” packed add-ons is available here. If you are an author of any of these add-ons, please release an update to your add-on that uses .jar packaging.
This bug is tracking the additional information:
https://bugzilla.mozilla.org/show_bug.cgi?id=413451
Status
Based on this new information Mozilla has changed the security severity rating to high. A fix is included in Firefox 2.0.0.12 which be available shortly.
chrome protocol directory traversal
January 22nd, 2008
Issue
A vulnerability in the chrome protocol scheme allows directory traversal when a “flat” add-on is present resulting in potential information disclosure.
Impact
When a chrome package is “flat” rather than contained in a .jar the directory traversal allows escaping the extensions directory and reading files in a predictable location on the disk. Many add-ons are packaged in this way.
A visited attacking page is able to load images, scripts, or stylesheets from known locations on the disk. Attackers may use this method to detect the presence of files which may give an attacker information about which applications are installed. This information may be used to profile the system for a different kind of attack.
Some extensions may store information in Javascript files and an attacker may be able to retrieve those. Greasemonkey user scripts may be retrieved using this method. Session storage and preferences are not readable through this technique.
Users are only at risk if they have one of the “flat” packaged add-on installed. Examples of popular add-ons that are vulnerable include: Download Statusbar and Greasemonkey.
Status
Mozilla is currently investigating this information disclosure issue and has assigned it an initial severity rating of low. Details are available at: https://bugzilla.mozilla.org/show_bug.cgi?id=413250
Credit
Gerry Eisenhaur first posted details of this issue along with proof of concept code at http://www.hiredhacker.com/2008/01/19/firefox-chrome-url-handling-directory-traversal/.
Read past the headlines - Firefox is fixed faster
January 17th, 2008
Secunia released a report this week that discusses a few aspects of the security landscape for 2007. Techworld ran a story based on this report with this headline: “Red Hat and Firefox more buggy than Microsoft.” While the headline is misleading, the Techworld article actually tells an interesting story.
Counting security vulnerabilities to compare the security of different software projects is flawed. It is only a useful metric if you are comparing a project to itself over time. I’ve discussed this topic here and here. It’s even more ridiculous to try and compare an open source bug count to a closed source project because you can see all the bugs in an open source project. You can only see the publicly found security issues for a closed source product, like Internet Explorer.
So what is interesting in the Techworld article is the measures of real risk to users:
“‘[Z]ero-day’ security bugs in Firefox were patched more quickly than in Microsoft Internet Explorer…”
“[I]n an examination of zero-day flaws - reported by third parties before a patch was available - Secunia found that Firefox tended to get more patches, sooner, compared to IE.”
“Out of eight zero-day bugs reported for Firefox in 2007, five have been patched, three of those in just over a week. Out of 10 zero-day IE bugs, only three were patched and the shortest patch time was 85 days.”
At Mozilla we work as hard as we can to ship fixes as soon as possible to minimize the exposure to our users. It is great to see that the efforts we are making to minimize risk to users are paying off.
BasicAuth dialog realm value spoofing
January 4th, 2008
Issue
The realm value in a basic authentication dialog may be spoofed by a attacker to trick users into thinking the authentication request is coming from a different, trusted site.
Impact
When displaying the basic authentication dialog, Firefox displays the actual source of the request at the end of the dialog text. Some other browsers display the request source at the very beginning of the dialog text or as part of the pop-up window’s title bar, which may be less likely to be confused.
This may allow an attacker to craft basic authentication dialogs that are confusing to users and may result in users sending website credentials to phishing websites.
Status
Mozilla is currently investigating this issue and has assigned it an initial security severity rating of low. You can follow this issue here: https://bugzilla.mozilla.org/show_bug.cgi?id=244273
Credit
The issue was reported to the full-disclosure and bugtraq mailing lists by Aviv Raff.
http://aviv.raffon.net/2008/01/02/YetAnotherDialogSpoofingFirefoxBasicAuthentication.aspx
Critical Vulnerability in Microsoft Metrics
November 30th, 2007
Jeff Jones, a director of security strategy at Microsoft published a report today about counting bugs. I blogged a few months ago about why I think counting bugs is less than useful:
Since all software has bugs, it’s more important to consider how long it takes to get a fix out when a security issue is discovered than it is to count bugs. Number of vulnerabilities identified is a function of how many bugs are present, but is probably more influenced by things like who is looking, and how good they are at finding security issues. That makes it a misleading metric.
When you compare how long it takes Microsoft to fix Internet Explorer vulnerabilities versus how long it takes Mozilla to fix vulnerabilities in Firefox it becomes clear why he chose to count vulnerabilities in this report instead. Earlier this year Brian Krebs of the Washington Post came up with this when comparing IE to Firefox:
For a total 284 days in 2006 (or more than nine months out of the year), exploit code for known, unpatched critical flaws in pre-IE7 versions of the browser was publicly available on the Internet…
In contrast, Internet Explorer’s closest competitor in terms of market share — Mozilla’s Firefox browser — experienced a single period lasting just nine days last year in which exploit code for a serious security hole was posted online before Mozilla shipped a patch to remedy the problem.
Mike Schroepfer goes into this in more detail in his post today.
One of the goals of the bug counting report is to demonstrate that Microsoft fixed fewer bugs for IE than Mozilla did for Firefox. Unfortunately for Microsoft (and for anyone trying to use this report as analysis of useful metrics) he does not count all the security issues. If he were able to count them all, Microsoft could get credit for all the bugs they fixed. He counts only the public issues, because that is all Microsoft will tell us about. Microsoft is worried that if it ever says it has fixed X security issues, the world will focus on that it had X vulnerabilities in the first place, not that they are now fixed and no longer a risk for users. So the set of issues that are available for public comparison is limited to the set of vulnerabilities that are reported externally AND fixed in security updates.
This is a small subset of all the vulnerabilities, because the vulnerabilities that are found through the QA process and the vulnerabilities that are found by the security folks they engage as contractors to perform penetration testing are fixed in service packs and major updates. For Microsoft this makes sense because these fixes get the benefit of a full test pass which is much more robust for a service pack or major release than it is for a security update.
Unfortunately for Microsoft’s users this means they have to wait sometimes a year or more to get the benefit of this work. That’s a lot of time for an attacker to identify the same issue and exploit it to hurt users. Sometimes it just takes time to put in a complicated fix. Anyone that has shipped a major piece of software can relate to that. But this is not the case for every internally found security issue. Extending this process to include fixes that are ready and just sitting on the tree waiting for the preferred vehicle to ship increases risk for users. But it sure keeps those bug count numbers down.
If we as an industry would just acknowledge that counting bugs is useless then vendors could feel safe talking about what they are doing to protect users. At Mozilla we fix our bugs openly. When you count Mozilla security bugs you are seeing not just those that are reported externally, but also the ones that would be considered internal if we acted like most other software vendors. Since all software has security vulnerabilities, we consider a vulnerability identified and fixed a win. It speaks to the strength of our community based security efforts to actively identify and quickly fix security issues. We don’t let fixes languish on the tree waiting for a major release while users are vulnerable. We ship fixes regularly because securing our users is more important than protecting our PR team from having to respond to articles about counting bugs instead of looking at the metrics that actually indicate whether a vendor is doing reasonable things to keep users secure.
We’re not building fixes for our PR team, we’re building them for our users. Go ahead and count.
Vulnerability in Apple QuickTime
November 27th, 2007
Krystian Kloskowski reported a buffer overflow in QuickTime versions 7.2 and 7.3. An attacker can lure a victim to load a web page with an embedded media object or a file in an email, triggering a bounds checking error in QuickTime that may allow execution of arbitrary code. This issue impacts QuickTime on Windows and on Mac OS and there is proof-of-concept code publicly available.
If QuickTime is set as the default media player, Firefox will send the request directly to QuickTime. Mozilla is currently investigating this issue to identify ways to protect Firefox users.
More information is available in the CERT report.
jar: Protocol XSS Security Issues
November 16th, 2007
Issue
jar: protocol is not restricted to java archives and will open any zip format file. An attacker can use this to evade filtering on sites that allow users to upload content and use this initiate a cross site scripting attack.
Impact
Firefox supports the Java Archive URI scheme that allows the addressing of the contents of zip archives. An attacker may upload a zip format file to a trusted site that allows users to upload content. The victim clicks on a link on the attacker’s website or in an email that links to the uploaded content on a trusted site. Since the content is loaded from the trusted site, content from the zip file runs in the context of the trusted site. This may allow the attacker to access information stored on the trusted site without the victim’s knowledge.
There is a second issue that if a zip archive is loaded from a site through a redirect, Firefox uses the context from the initiating site. This allows an attacker to take advantage of a site with an open redirect and host content on their own malicious site that will execute with the permissions of the redirecting site.
There is a proof of concept that demonstrates these issues in an attack against Gmail that allows the attacker access to the victim’s stored Gmail contacts.
Status
In future versions Firefox will only support the jar scheme for files that are served with the correct application/java-archive MIME type. Firefox will also adjust the security context to recognize the final site as the source of the content. This will be addressed in Firefox 2.0.0.10, which is currently in testing.
You can follow our work in bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=369814
https://bugzilla.mozilla.org/show_bug.cgi?id=403331
Credit
These issues were identified by Jesse Ruderman, Petko D. Petkov, and beford.org.
Next Page »