Status update for Chrome Protocol Directory Traversal issue

Window Snyder

3

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

Window Snyder

3

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

Window Snyder

5

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

Window Snyder

1

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

Window Snyder

14

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

Window Snyder

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

Window Snyder

1

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.

Firefox 2.0.0.8 now available

Window Snyder

Firefox 2.0.0.8 was released yesterday as part of our continuing efforts to improve the security of the web browser.  This security update contains fixes for security issues described here and an additional mitigation for Windows URI handling security issues.  Please be sure to update your installation of Firefox when automatic update asks, or to get it immediately choose “Check for Updates” from the Help menu.

Meet the Mozilla Security Group

Window Snyder

How can Mozilla be open about security issues without exposing users to additional risk?

Being open about security issues means that users have the information they need to understand their risk, that the community can contribute to the security process, and that other software development projects can benefit from our experiences.  Unfortunately, sharing the details of security issues broadly before they are patched could expose users to risk. The balance we have come up with is to work with a group of people that represent the interests of the entire community who can give feedback, suggestions, and help to fix security issues.

The Mozilla Security Group is a team of people from the community, including employees, individual contributors, and other vendors who work on securing Mozilla projects. This group has been in place since 2002, is older than Mozilla Corporation, and as of today there are 93 people in the group. The team is self-organizing. New members are nominated by existing members through recognition of valuable contributions to security efforts. This system is democratic and is similar to the method used to assign rights to add code to Mozilla projects for new contributors.

This team enables us to leverage the knowledge of the community, be open about security issues, but also protect our users until we are able to ship a fix.

Firefox 2.0.0.7 now available

Window Snyder

Firefox 2.0.0.7 was released this afternoon to patch the QuickTime issue described here. This will protect Firefox users from the public critical security vulnerability until a patch is available from Apple. I would like to personally thank the individuals at Apple who worked with us and the engineers at Mozilla that work so hard to get security updates out so quickly.

This issue was patched in only six (or 6.25 according to John O’Duinn) days. When a vendor ships security fixes quickly, it lowers the incentive for attackers to spend time developing and deploying an exploit for that issue. The window of opportunity for attackers is reduced and so is the potential to compromise users. So thanks you guys, for helping destroy the economics of malicious exploit development.

http://www.mozilla.org/security/announce/2007/mfsa2007-28.html