Previously Firefox would automatically load any plugin requested by a website. Leveraging Click to Play Firefox will only load plugins when a user takes the action of clicking to make a particular plugin play or the user has previously configured Click To Play to always run plugins on the particular website.

More User Control
Users should have the choice of what software and plugins run on their machine. Click to Play allows users to easily choose if they wish to run a plugin on a particular site. Users can also configure sites to never run plugins or conversely always run plugins. This change puts the user in control.

Increased Performance & Stability
Poorly designed third party plugins are the number one cause of crashes in Firefox and can severely degrade a user’s experience on the Web. This is often seen in pauses while plugins are loaded and unloaded, high memory usage while browsing, and many unexpected crashes of Firefox. By only activating plugins that the user desires to load, we’re helping eliminate pauses, crashes and other consequences of unwanted plugins.

Significant Security Benefits
One of the most common exploitation vectors against users is drive by exploitation of vulnerable plugins. In this kind of attack, a user with outdated or vulnerable plugins installed in their browser can be infected with malware simply by browsing to any site that contains a plugin exploit kit. We’ve observed plugin exploit kits to be present on both malicious websites and also otherwise completely legitimate websites that have been compromised and are unknowingly infecting visitors with malware. In these situations the website doesn’t have any legitimate use of the plugin other than exploiting the user’s vulnerable plugin to install malware on the their machine. The Click to Play feature protects users in these scenarios since plugins are not automatically loaded simply by visiting a website.

In addition to the security benefits provided by Click to Play Mozilla also strongly recommends that users keep their plugins up to date. The following website can be used to determine if plugins are current.
https://www.mozilla.org/plugincheck/

Implementing this change
Our plan is to enable Click to Play for all versions of all plugins except the current version of Flash. Click to Play has already been enabled for many plugins that pose significant security or stability risks to our users. This includes vulnerable and outdated versions of Silverlight, Adobe Reader, and Java.

More specifically, our next steps are the following:
1. Click to Play old versions of Flash (versions <=10.2.*) and slowly add more recent insecure Flash versions to the Click to Play list. Note: The most current version of Flash will NOT have Click To Play.

After we complete final UI work:
2. Click to Play current versions of Silverlight, Java, and Acrobat Reader and all versions of all other Plugins.

During this change we will monitor the results and feedback of the new settings and UI to ensure we’re providing a quality experience and delivering the many benefits of Click to Play to Firefox users.

Michael Coates
Director of Security Assurance

Impact
An attacker could exploit this vulnerability to execute malicious software on a victim’s machine. This vulnerability is being actively used in attacks and the malicious exploit code is also available in common exploit kits.

Demo screenshot of Click To Play

Issue

TURKTRUST, a certificate authority in Mozilla’s root program, mis-issued two intermediate certificates to customers. TURKTRUST has scanned their certificate database and log files and confirmed that the mistake was made for only two certificates.

This is not a Firefox-specific issue. Nevertheless, we are concerned that at least one of the mis-issued intermediate certificates was used for man-in-the-middle (MITM) traffic management of domain names that the customer did not legitimately own or control. We are also concerned that the private keys for these certificates were not kept as secure as would be expected for intermediate certificates.

Impact

An intermediate certificate that is used for MITM allows the holder of the certificate to decrypt and monitor communication within their network between the user and any website. Additionally, If the private key to one of the mis-issued intermediate certificates was compromised, then an attacker could use it to create SSL certificates containing domain names or IP addresses that the certificate holder does not legitimately own or control. An attacker armed with a fraudulent SSL certificate and an ability to control their victim’s network could impersonate websites in a way that would be undetectable to most users. Such certificates could deceive users into trusting websites appearing to originate from the domain owners, but actually containing malicious content or software.

Status

Mozilla is actively revoking trust for the two mis-issued certificates which will be released to all supported versions of Firefox in the next update on Tuesday 8th January.

We have also suspended inclusion of the “TÜRKTRUST Bilgi İletişim ve Bilişim Güvenliği Hizmetleri A.Ş. (c) Aralık 2007” root certificate, pending further review.

Additional action regarding this CA will be discussed in the mozilla.dev.security.policy forum.

Credit

This issue was initially reported to us by Google, Inc.

Michael Coates
Director of Security Assurance

Individuals’ security on the Internet is fundamental and cannot be treated as optional. http://www.mozilla.org/about/manifesto.html

Open & Transparent

• Threat Modeling – During design we gather security experts, developers and architects to evaluate potential risks of a design and ensure proper security controls are present in the design of the new system or feature.
• Fuzzing – Automated scripts and tools send a variety of malformed data into our applications to ensure our products properly handle all sorts of unexpected scenarios that could otherwise lead to vulnerabilities.
• Security Code Review – Our security experts and developers manually review critical code to identify the proper use of security controls and proactively find potential flaws.
• Penetration Testing – We perform the same actions that a real attacker would take against our applications and ensure all security defenses are properly functioning.
• Bug Bounty Program – Mozilla began the first browser bug bounty program in 2004 and expanded to include critical web applications in 2010.  This program builds our larger security community and is another way we proactively discovery security issues and provide fixes long before users are ever at risk.

Results?

Our secure software development lifecycle allows us to proactively harden our applications and fix potential security concerns. In fact, since 2010 we’ve only had three public security zero-days (potentially exploitable security vulnerabilities in the current version) within our Firefox code that has caused us to rapidly release a security fix. When these situations arise we deliver fixes to our users in an average of under 48 hours.

Yesterday Oracle released a patch for the critical vulnerabilities identified within Java.

Visit the Mozilla Plugin Check webpage to find out if your Java plugin needs to be updated:
https://www.mozilla.org/plugincheck/

Additional information from Oracle can be found here:
https://blogs.oracle.com/security/entry/security_alert_for_cve_20121

Update – Aug 29, 2012:

We’ve been closely monitoring the recent Java security vulnerability and evaluating different options to best protect our users.

Our goal is to provide protection to Firefox users against this actively exploited vulnerability in Java while also leaving the user in control so they can choose to allow Java on important sites that they trust.

We are still working out the implementation details, but our solution will accomplish two primary objectives:

1. By default, vulnerable versions of Java will be disabled for our Firefox users.
2. Users will be provided the option to enable Java through a clear and visible message that will be displayed anytime the user views a page using Java.

We’ll provide additional updates when items are finalized. In the interim, we still advise users to disable the Java plugin as described below.

Lastly, starting this week in Aurora and Beta we’ll begin adding the components of click-to-play, a Firefox security control that helps protect users against outdated and vulnerable plugins. We anticipate this new security feature to be fully operational by Firefox 18.

Original Post Aug 28, 2012

Issue

Mozilla is aware of a security vulnerability (CVE-2012-4681) in the current version of Java 7 (version 1.7, updates 0 through 6) that is being actively exploited to compromise users. Firefox users may be vulnerable to this issue if they are running the Java plugin within their browser.

Impact to Users

An attacker could exploit this vulnerability to download and execute malware on to a user’s machine.

We have received reports of this vulnerability being actively used in targeted attacks and the malicious exploit code is also available in common exploit kits indicating the number of attacks may increase.

Status

At this time there is no patch available from Oracle to address the vulnerability within Java. We recommend that users disable the Java plugin within Firefox to ensure they are protected against this vulnerability.

Steps to disable the Java plugin can be found here:
http://support.mozilla.org/kb/How+to+turn+off+Java+applets

The pwn2own bug that Nils discovered at CanSecWest 2009 and the XSLT vulnerability recently made public by Guido Landi (http://www.securityfocus.com/bid/34235) are both critical issues that can result in malicious code execution.

Impact

These issues can be exploited by tricking a user into visiting a malicious web page hosting the exploit code. The pwn2own bug can be mitigated by disabling JavaScript.

Status

Both issues have been investigated and fixes have been developed which are now undergoing quality assurance testing. These fixes will be included in the upcoming Firefox 3.0.8 release, due to be released by April 1. You can follow our work in bugzilla.

Credit

The pwn2own bug was reported to Mozilla by Nils via the Zero Day Initiative (ZDI). The XSLT issue was discovered on http://www.milw0rm.com/exploits/8285, credited to Guido Landi.

Bit9 says it drew up this list by identifying popular applications that have had a critical vulnerability reported in 2008. This is an ineffective test, as it rewards software companies that conceal their security vulnerabilities. Mozilla focuses a great deal of energy on building world class code, and we stand by our reputation on security; we don’t play games with it.

Mozilla security process involves regularly identifying, fixing, testing, and releasing security updates to keep our users safe, and we do that in a public way so that others can scrutinize our processes and help make them better. To suggest that this openness is a weakness because it means that we have “reported vulnerabilities” is to miss the reality: that software has bugs. A product’s responsiveness to those bugs and its ability to contain them quickly and effectively is a much more meaningful metric than counting them.

Bit9 seems to understand this in its focus on application support for updates, but again it fails to account for the real world experience.  Firefox does not deliver WSUS updates, but our built-in update mechanism requires no user intervention, and we consistently see 90% adoption within six days of a new update being released.

The Firefox vulnerabilities Bit9 discusses are long-since fixed, with the majority of these fixes coming within days of it being announced.  That is the real measure of application security: are known vulnerabilities fixed promptly, tested carefully, and deployed thoroughly? When people have asked that question, Firefox and Mozilla have consistently come out ahead.

Bug counting is unfortunately common because it’s easy, but it should not be a substitute for real security measurement. This is why we’ve continued to work on things like the Mozilla security metrics project, to help people make informed decisions about the security of their software. We invite people who are interested to be a part of that process.

Johnathan Nightingale
Human Shield

This is great news for Mozilla, since it demonstrates that the work that has gone into the auto update mechanism and the restore session feature has really paid off.  In order to reduce the window of risk for users and minimize the time to deploy, we have put a lot of effort into making sure that it is as easy to install security updates as possible.  This is not the first time we have heard this, but it is great to get more numbers behind what we already know:  Firefox is safer because Mozilla continually works on security improvements, ships updates quickly, and makes it easier to stay up-to-date.

You will be hearing more about our effort to collect meaningful security metrics like these soon.

Asa has a few words to say about this on his blog.

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.