We hate crashes. When Firefox crashes, we try to get you back on your feet as quickly as possible, but we’d much rather you not crash in the first place. In Firefox 3.6, we are changing the way that some third party software hooks into Firefox which should eliminate a good chunk of those crashes without sacrificing our extensibility in any way. In the process, we’ll also be giving you greater control over the code that runs in your browser.

Background

Firefox is built around the idea of extensibility – it’s part of our soul. Users can install extensions that modify the way their browser looks, the way it works, or the things it’s capable of doing. Our add-ons community is an amazing part of the Mozilla ecosystem, one we work hard to grow and improve.

In addition to the standard mechanism for extending the browser via add-ons and plugins, though, there has historically been another way to do it. Third-party applications installed on your machine would sometimes try extend Firefox by just adding their own code directly to the “components” directory, where much of Firefox’s own code is stored.

There are no special abilities that come from doing things this way, but there are some significant disadvantages. For one thing, components installed in this way aren’t user-visible, meaning that users can’t manage them through the add-ons manager, or disable them if they’re encountering difficulties. What’s worse, components dropped blindly into Firefox in this way don’t carry version information with them, which means that when users upgrade Firefox and these components become incompatible, there’s no way to tell Firefox to disable them. This can lead to all kinds of unfortunate behaviour: lost functionality, performance woes, and outright crashing – often immediately on startup.

In Firefox 3.6 (including upcoming beta refreshes), we’re closing this door. Third party applications can still extend Firefox via add-ons and plugins the way they always could, but the components directory will be for Firefox only.

What Does This Mean For Me?

If you’re a Firefox user, this should be 100% positive. You don’t have to change anything, your regular add-ons should continue to work properly – you just might notice fewer crashes or odd bugs. If you do notice that something has stopped working, particularly a third party addition to Firefox, you might want to contact the producer of that addition to ensure they know about the change.

If you’re a Firefox component developer, this shouldn’t be a big change, either. If you’re already packaging your additions as an XPI, installed as an add-on it’s business as usual. If you have been dropping components directly, though, you’ll need to change to an XPI-based approach. Our migration document on the Mozilla Developer Connection outlines the changes you’ll need to make, and should be pretty straightforward. The good news is that once you’ve done this, your add-on will actually be visible to users and will support proper version information so that our shared users are guaranteed a more positive experience.

If you haven’t downloaded the new Firefox beta yet, and want to give it a spin, you can find a copy here.

Johnathan Nightingale
Human Shield

In it, he discusses the current state of affairs, the series of events that got us to this point, as well as the steps we, and Microsoft, are taking to get the situation resolved.

Today, we’re bringing the rest of the story. Our web team has just pushed the full plugin check page live, checking the status of more than 15 popular plugins, with more still in the works. Visitors to the page can see which plugins they have installed and, for any that are outdated, follow an easy link to the update site.

In the upcoming release of Firefox 3.6, we’ll also include built-in support for helping users keep up to date. When you visit a page with Firefox 3.6, we’ll use this same service to let you know if any of the plugins used on the site have updates available.

We’ve got a pretty strong list of plugins and versions already but we’ll continue to maintain and grow it based on our conversations with plugin authors and our users. If you want more information, or are interested in helping out, check out the web team’s post. Did the plugin check uncover any surprises for you?

Johnathan Nightingale
Human Shield

]]> http://blog.mozilla.com/security/2009/10/13/mozilla-plugin-check-now-live/feed/ 16 http://blog.mozilla.com/security/2009/09/30/a-glimpse-into-the-future-of-browser-security/ http://blog.mozilla.com/security/2009/09/30/a-glimpse-into-the-future-of-browser-security/#comments Wed, 30 Sep 2009 21:42:30 +0000 Brandon Sterne http://blog.mozilla.com/security/?p=176 As we mentioned earlier we’ve been working for the past few months on turning the Content Security Policy specification into working Firefox code. (You’ll remember that CSP is a framework to protect websites from XSS and related attacks). We are happy to report that the work is nearly finished, and we have some preview builds available for you to try out.

We’re thrilled to have received so much great feedback from other browser vendors, web site administrators, and security researchers and we’re very proud of the design that has come out of that discussion. We would like to encourage any server administrators or web app security researchers who are interested in this project to grab a preview Firefox build and help us test the new features. Please be aware that there are still a few rough spots. The implementation is not quite complete so you may notice some small gaps between the preview builds and the spec. Most notably, HTTP redirects are not fully handled by CSP (but will be soon).

I posted a demo page where you can see the basic features of CSP in action, though we’re all much more excited to see all the tests and proof points our friends in the security research community are sure to turn up. Please grab a preview build and start testing!

Brandon Sterne
Security Program Manager

After installing the Firefox security update, users with an out of date version of the Adobe Flash Player will see this message:

Our intent is to get the user’s attention, and direct them to the Adobe web site where they can download the most up to date version.

For users who are already running the latest version, or who don’t have the Adobe Flash Player installed, the page will look very much like what they would normally see after a Firefox security update:

Mozilla will work with other plugin vendors to provide similar checks for their products in the future. Keeping your software up to date remains one of the best things you can do to keep yourself safe online, and Mozilla will continue to look for ways to make that process as easy as possible for its users.

Johnathan Nightingale
Human Shield

Ken Kovash and Eric Hergenrader surveyed users who have update-checking enabled but repeatedly chose not to update from Firefox 2 to Firefox 3. Read their posts: Why People Don’t Upgrade Their Browser – Part I and Part II. It’s great to understand why these people continue to use Firefox 2 even when it is no longer receiving security updates.

The URL in the address bar can be spoofed when a new window or tab is opened by a malicious web page.

Impact to users

If a user visits a page hosting this malicious code, a new window or tab can be opened with a faked URL.  There is no way of determining if the URL is authentic.  This could result in the user disclosing confidential information to the malicious site, known as a phishing attack.

Status

This vulnerability is known to affect all current versions of Firefox.  Mozilla is actively working on fixing this vulnerability.  Users can mitigate this vulnerability by only sharing confidential information with websites that were opened from a bookmark, a trusted source, or by manually opening a new tab or window and entering a URL.

Credit

This issue was originally reported by Juan Pablo Lopez Yacubian.

HTTP Man-In-The-Middle (MITM) attacks

Consider your typical online banking session:  you type “www.mybank.com” into the address bar, hit enter, and wait for the site to load.  When it shows up, you enter your password, do your banking, then log out.  This process is more-or-less automatic for many people, and the subtleties of the process disappear in the background.  More specifically, these are the steps for logging into the bank’s site:

1.   You type “www.mybank.com” into the address bar and hit enter.
2.   The browser assumes “www.mybank.com” should be requested over HTTP by default, so the initial request is unencrypted.
3.   The server at “http://www.mybank.com” responds with an HTTP redirect to “https://www.mybank.com”
4.   The secure connection is established, and a login page is served via HTTPS.
5.   You enter your password and do your banking.

It is only after the first few swift (and often unnoticed) steps that the user is presented with a secure connection.  In a rogue hotspot, “www.mybank.com” might resolve to an attacker’s server (instead of the real thing) and the HTTPS connection may never happen.  Many users might not notice this and end up logging into an attacker’s website.

HTTPS is intended for both channel encryption, to thwart eavesdroppers, and for server authentication.  In the hotspot banking MITM situation, you may simply assume that no errors indicates a safe connection but in all reality the server has not been authenticated!   After all, you’re not presented with any warnings or UI indicators saying the site is an attack site.  If you’re a diligent user, you can always click Firefox’s site identity button to find out whether or not the site has authenticated itself and whether it’s encrypting to prevent eavesdropping, of course.  It’s hard to remember (and time consuming) to do that every time, especially when you’re used to logging into certain trustworthy sites automatically.  And in fact, a fake bank’s site may even have a little lock icon next to the login box that assures the user he is logging into a secure site –  many legitimate banking sites unfortunately do the same thing.

Asking the Browser to use HTTPS Only

To stop this kind of man-in-the-middle attack, where an HTTPS site is mimicked over HTTP, Collin Jackson and Adam Barth proposed something called ForceHTTPS in 2008.  This is a browser feature that allows web sites to tell a browser to always request it via HTTPS, and never unencrypted HTTP.  It was intended to help eliminate the redirect from HTTP to HTTPS and minimize the chance of an insecure attack as described above.

We like the idea of ForceHTTPS and are working on implementing it as “ForceTLS” in Firefox with hopes it will reduce occurrences of MITM attacks and generally improve user security.  We built an add-on as a first step prototype of the feature that works in a similar fashion to the original design by Jackson and Barth.  Instead of using cookies, however, we’re asking sites to send an HTTP header “X-Force-TLS” with any securely-transmitted response.  The name of this header will change in the future, but for now we’re using “X-Force-TLS” as the experimental header that, when present, means:

1. The browser should only attempt to access that domain via HTTPS
2. How long this requirement should last. For example, a server can ask the HTTPS-only request to expire after three days.  This expiration timer can be reset or changed every time data is served to the client by providing a new HTTP header.
3. Whether or not subdomains of the requested site (images.mybank.com, or login.mybank.com for example) should also be forced into HTTPS

ForceTLS can be used for more than just protection against evil hotspots; it can also be used to harden web applications against accidental unencrypted requests.  Many popular web apps can be used over both secure HTTPS and insecure HTTP connections; while you’re given the choice to pick HTTPS instead of HTTP, it’s possible that a large web app might have a HTTP URI referenced from some subtle corner of its code (by accident of course), and with Force TLS employed, this would quietly get upgraded to HTTPS and prevent exposing any unencrypted data on the network.

Check out our prototype, and tell us what you think!  The browser extension and source code are available on AMO (https://addons.mozilla.org/en-US/firefox/addon/12714).

Sid Stamm
Securinator

Crashes and security

Some Firefox crash bugs are severe security bugs. A crash bug is likely to be exploitable if it can be triggered by a web page and the bug is a memory safety bug such as calling a virtual method on a dangling pointer.

Although only a fraction of our crashes are exploitable, two thirds of our most severe security bugs are crashes. We’re striving to improve how we find and fix crash bugs, since the better we can find and fix the bugs, the more stable and secure Firefox will be.

Bug reports

When a user reports a bug, a loose team of volunteers tries to reproduce the bug, improve the bug report, and inform the correct developers about the bug.

The history of bug 503286 demonstrates the variety of skills involved in fixing crash bugs. Soon after zbyte filed the bug, Ria Klaassen reproduced the bug on her machine, captured a stack trace, and determined when the bug had been introduced. Volunteers Lucas and Natch reduced the web page to a simple testcase that demonstrated the bug. Using this information, JavaScript engine developers Andreas Gal and Blake Kaplan had little trouble creating a patch. All of this happened within 14 hours of the bug being reported.

Our current bug triage process is not perfect, and sometimes leaves valid bugs unprocessed. During this Tuesday’s crash bug triage day, we will experiment with a new triage workflow that should be both more efficient and more effective. If you’d like to help clear the crash bug backlog, please join us in #bugday this Tuesday (2009-07-21).

Reporting bugs requires substantial effort from users, and requires both English-language and technical skills, so we prefer not to rely exclusively on user-reported bugs. Luckily, crashes are easier to detect automatically than most other types of bugs, so we can find many of them using other methods.

Crash reports

Whenever Firefox crashes, a dialog appears that allows users to submit information about the crash to Mozilla. Although the average Firefox user only sends 1.5 crash reports per year, this information is valuable in aggregate.

Currently, our main use for these crash reports is to identify the most common crashes. If a crash is common but has not been reported in Bugzilla, we can look at the comments that come with some crash reports to get an idea of what triggers the crash.

Fixing common crashes is enough to make Firefox stable for most users, but even a rare crash could be a security hole, so we need to do more. To address this issue, Mozilla is creating a “crash reproduction farm” of computers that will automatically load URLs that come with crash reports. This will let us identify and fix most crashes that result from simply loading a web page.

Fuzz testing

Fuzz testing is the art of creating random input for software in order to find bugs. We do extensive fuzz testing of our most complex components, such as the JavaScript engine. Fuzz testing finds two thirds of the exploitable crashes we fix, including many that are too obscure for normal web sites to trigger.

Fixing crash bugs

For developers who are familiar with the relevant code, crashes are often easier to debug and fix than they are to find. To identify the developers familiar with the code, you can click the source code links in crash reports and see who last touched each line of code.

Jesse Ruderman
Security bug hunter

Details

On Windows, Firefox 3.0.x and Firefox 3.5.x are terminated due to an uncaught exception during an attempt to allocate a very large string buffer; this termination is safe and immediate, and does not permit the execution of attacker code.

On the Macintosh in Firefox 3.0.x and 3.5.x, a crash occurs inside the ATSUI system library (part of OS X), due to what appears to be a failure to check allocation results. This issue is likely to affect any application using the recommended text-handling libraries on OS X. We have reported this issue to Apple, but in the event that they do not provide a fix we will look to implement mitigations in Mozilla code. We recommend that other developers who use these libraries consider a similar practice, and we have added mitigations in the past for similar bugs in these libraries.

On Linux, the problem is similar to that on Mac: there is an abort in system libraries (pango, glib, libc). Due to the wide variation of Linux libraries and versions deployed, and different compilation options chosen by Linux distributors for Firefox, the details of the crash report may vary between machines.

As a result of our analysis, we do not believe that this represents an exploitable vulnerability in Firefox. Further, we believe that the IBM report is in error, and that the severity rating in the National Vulnerability Database report is incorrect. We have contacted them and hope to resolve the inaccuracies shortly.

[Updated (July 19, 8:50pm EDT): thanks to Larry Seltzer for bringing to our attention that Firefox 3.5.x will indeed still crash using the provided PoC on Windows, at least for some users.]

[Updated (July 20, 8:50am EDT): the SecurityFocus report has been updated to indicate that it is only a denial of service issue. This is consistent with our analysis; thanks to SecurityFocus for correcting their error.]

[Updated (July 20, 9:15am EDT): added results for Linux, thanks to Kevin Brosnan.]

Mike Shaver
VP Engineering, Mozilla Corporation