Three central issues informed our decision:

1) Failure to notify. DigiNotar detected and revoked some of the fraudulent certificates 6 weeks ago without notifying Mozilla. This is particularly troubling since some of the certificates were issued for our own addons.mozilla.org domain.

2) The scope of the breach remains unknown. While we were initially informed by Google that a fraudulent *.google.com certificate had been issued, DigiNotar eventually confirmed that more than 200 certificates had been issued against more than 20 different domains. We now know that the attackers also issued certificates from another of DigiNotar’s intermediate certificates without proper logging. It is therefore impossible for us to know how many fraudulent certificates exist, or which sites are targeted.

3) The attack is not theoretical. We have received multiple reports of these certificates being used in the wild.

Mozilla has a strong history of working with CAs to address shared technical challenges, as well as responding to and containing breaches when they do arise. In an incident earlier this year we worked with Comodo to block a set of mis-issued certificates that were detected, contained, and reported to us immediately. In DigiNotar’s case, by contrast, we have no confidence that the problem had been contained. Furthermore, their failure to notify leaves us deeply concerned about our ability to protect our users from future breaches.

Staat der Nederlanden Certificates

DigiNotar issues certificates as part of the Dutch government’s PKIoverheid (PKIgovernment) program. These certificates are issued from a different DigiNotar-controlled intermediate, and chain up to the Dutch government CA (Staat der Nederlanden). The Dutch government’s Computer Emergency Response Team (GovCERT) indicated that these certificates are issued independently of DigiNotar’s other processes and that, in their assessment, these had not been compromised. The Dutch government therefore requested that we exempt these certificates from the removal of trust, which we agreed to do in our initial security update early this week.

The Dutch government has since audited DigiNotar’s performance and rescinded this assessment. We are now removing the exemption for these certificates, meaning that all DigiNotar certificates will be untrusted by Mozilla products. We understand that other browser vendors are making similar changes. We’re also working with our Dutch localizers and the Bits of Freedom group in the Netherlands to contact individual site operators using affected certificates (based on the EFF’s SSL Observatory data).

The integrity of the SSL system cannot be maintained in secrecy. Incidents like this one demonstrate the need for active, immediate and comprehensive communication between CAs and software vendors to keep our collective users safe online.

Johnathan Nightingale
Director of Firefox Engineering

Plugin Check: A Refresher

Last fall, we started a program to help our users keep their plugins up to date. Outdated plugins are a major source of security and stability risk for web users, and some studies have put the proportion of users with older versions as high as 80%.

In the months since we’ve deployed the page, we’ve seen some great success. These days, over 60% of the users we see on the plugin check page with Adobe’s Macromedia Flash plugin installed are running the most recent version, and the number grows to more than 75% if we include the second most recent. That’s much higher than the web as a whole, and there is still a lot of work to do to get that number up, but we’re confident that the integrated checks for outdated plugins in Firefox 3.6 will improve things even further.

What’s New

We believe that plugin safety is an issue for the web as a whole, so while our initial efforts focused on building a page that would work for Firefox users, the team has since expanded plugin check coverage to work with Safari 4, Chrome 4, and Opera 10.5. We have added support for Internet Explorer 7 and 8 for the most popular plugins, as well, but since IE requires specific code to be written for each plugin it will take us a little longer to get to full coverage. You can see the updated page for yourself here.

This has been a phenomenal amount of work to develop and test, and the matrix of browser, plugin and OS grows very quickly. Our web team is remarkable, but they couldn’t have done it without the continuing support of Mozilla community members like Lloyd Hilaiel who helped write some of the plugin-specific logic.

Plugin Check Badges

Finally, now that we have delivered a more universal plugin check page, I wanted to call your attention to the plugin check site badges our team developed a little while ago. Adding these banners to your site will help your readers stay current regardless of which browser they use, and make the internet a safer place for everyone.

One More Request

Our Plugin Directory will eventually become the main way we keep our data about plugins up-to-date. If you’re a plugin vendor, we need your help! The directory is currently in alpha stages, and we need vendors to let us know as new versions come out, and old versions become dangerous. Please email plugindir @ mozilla . com for information about how you can get involved.

Johnathan Nightingale
Director of Firefox Development

We’re close to landing some changes in the Firefox development tree that will fix a privacy leak that browsers have been struggling with for some time. We’re really excited about this fix, we hope other browsers will follow suit. It’s a tough problem to fix, though, so I’d like to describe how we ended up with this approach.

History Sniffing

Links can look different on web sites based on whether or not you’ve visited the page they reference. You’ve probably seen this before: in some cases, visited links are purple instead of blue. This is just one of the many features web designers use to make the web the best it can be, and for the most part that’s a good thing.

The problem is that appearance can be detected by the page showing you links, cluing the page into which of the presented pages you’ve been to. The result: not only can you see where you’ve been, but so can the web site!

Originally specified as a useful feature for the Web, visited link styling has been part of the web for… well, forever. So this is a pretty old problem, and resurfaces every once in a while to generate more paranoid netizens.

The most obvious fix is to disable different styles for visited versus unvisted links, but this would be employed at the expense of utility: while sites can no longer figure out which links you’ve clicked, neither can you. David Baron has implemented a way to help keep users’ data private while minimizing the effect on the web, and we are deploying it to protect our users. We think this represents the best solution to the problem, and we’ll be delighted if other browsers approach this the same way.

Technical Details.

The biggest threats here are the high-bandwidth techniques, or those that extract lots of information from users’ browsers quickly. These are particularly worrisome since they enable not only very focused attacks, but also the widespread brute-force attacks that are, in general, more useful to a variety of attackers (potentially including fingerprinting).

The JavaScript function getComputedStyle() and its related functions are fast and can be used to guess visitedness at hundreds of thousands of links per minute. To make it harder for web sites to figure out where you’ve been without radically changing the web, we’re approaching the way we style links in three fairly subtle ways:

Change 1: Layout-Based Attacks
First of all, we’re limiting what types of styling can be done to visited links to differentiate them from unvisited links. Visited links can only be different in color: foreground, background, outline, border, SVG stroke and fill colors. All other style changes either leak the visitedness of the link by loading a resource or changing position or size of the styled content in the document, which can be detected and used to identify visited links.

While we are changing what is allowed in CSS, the CSS 2.1 specification takes into consideration how visited links can be abused:

“UAs may therefore treat all links as unvisited links, or implement other measures to preserve the user’s privacy while rendering visited and unvisited links differently.” [CSS 2 Specification]

Change 2: Some Timing Attacks
Next, we are changing some of the guts of our layout engine to provide a fairly uniform flow of execution to minimize differences in layout time for visited and unvisited links. The changes cause all styles to be resolved on all links for both visited and unvisited states, and it is stored; then, when the link is styled, the appropriate set of styles is chosen making the code paths for visited and unvisited links essentially the same length. This should eliminate some of the easy-to-mount timing attacks.

Change 3: Computed Style Attacks
JavaScript is not going to have access to the same style data it used to. When a web page tries to get the computed style of a link (or any of its sub-elements), Firefox will give it unvisited style values.

What does this mean for users?

For the most part, users shouldn’t notice a change in how the web works. A few web sites may look a little different, but visited links will still show up differently colored. A few sites that use more than color to differentiate visited links may look slightly broken at first while they adjust to these changes, but we think it’s the right trade-off to be sure we protect our users’ privacy. This is a troubling and well-understood attack; as much as we hate to break any portion of the web, we need to shut the attack down to the extent we can.

We have to be realistic, though: there are many ways all browsers leak information about you, and fixing CSS history sniffing will not block all of these leaks. But we believe it’s important to stop the scariest, most effective history attacks any way we can since it will be a big win for users’ privacy.

If the remaining attacks worry you, or you can’t wait for us to ship this fix, version 3.5 and newer versions of Firefox already allow you to disable all visited styling (immediately stops this attack) by setting the layout.css.visited_links_enabled option in about:config to false. While this will plug the history leak, you’ll no longer see any visited styling anywhere.

Enhancing Privacy on the Web.

We want to bridge the gap between our users’ expectations of privacy and what actually happens on the web. Sometimes users have an expectation that we preserve their privacy a certain way, and if we can, we want to live up to it. Privacy isn’t a feature that can simply be added to a browser, though; it often comes at the expense of utility. We think we’ve found a fix that will balance flexibility for web developers while providing a safer experience for our users on the web.

Sid Stamm, Mozilla Security

For additional information please see Mozilla Foundation’s Security Advisory MFSA-10-08 as well as the Firefox 3.6.2 Release Notes. We urge users to promptly update to this release by selecting “Check for Updates…” from the “Help” menu, or by visiting https://www.mozilla.com/ for a free download.

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/2008/12/10/leaving-mozilla/ http://blog.mozilla.com/security/2008/12/10/leaving-mozilla/#comments Wed, 10 Dec 2008 19:15:12 +0000 Window Snyder http://blog.mozilla.com/security/?p=48 I will be leaving Mozilla at the end of the year.  I am sad to be leaving, but I am excited to go work on something I have always been passionate about.  I wish I could tell you about it now, but that will have to wait for a while.

You will still get Mozilla security information here. Johnathan Nightingale, Lucas Adamski, Brandon Sterne and Mike Shaver will all be posting on the Mozilla security blog to keep users informed about security issues and announcements.  I leave you in their very capable hands and wish them the best of luck.

The Mozilla community is an incredible group of dedicated people who are really making a difference in how we experience the Internet.  The contribution you make to the world is tremendous.  I am honored to have been a small part of it for these last few years.

Thank you,
Window

Window Snyder
window@dec.net

Below is a summary of the project goals, and the xls of the model is posted at http://securosis.com/publications/MozillaProject2.xls.  The same content as a set of .csvs is available here: http://securosis.com/publications/MozillaProject.zip [Update] There also a copy for OpenOffice: http://securosis.com/publications/MozillaProject2.ods

This is a preliminary version and we are currently looking for feedback. The final version will be a far more descriptive document, but for now we are using a spreadsheet to refine the approach. Feel free to download it, rip it apart, and post your comments. This is an open project and process.  Eventually we will release this to the community at large with the hope that other organizations can adapt it to their own needs.

We would love to get your opinions on this, and if you are not comfortable commenting here you can mail Rich directly at rmogull@securosis.com.  When we have reviewed the feedback, we will post here with findings and continue the effort with your help.

Project Mission:
To develop a metrics based model to track the relative security of Firefox, evaluate the effectiveness of security efforts within the development and testing process, and measure the window of exposure of Firefox users to security vulnerabilities.

Secondary mission:
To develop an open base model that can be standardized and expanded upon for other software development efforts to achieve the same goals.

Detailed goals:
1. Track security trends in the development of Firefox.
2. Measure the effectiveness of various tools, stages and techniques of secure development.
3. Measure the exposure window when new vulnerabilities are discovered- the time to get x% of the user base protected. Will include sub-metrics to measure the efficiency of the process, from initial response, through patch generation, through user base updated.  Correlate by severity of vulnerability.

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