Mozilla Security Blog

Firefox 23 moved from Nightly to Aurora this week, bundled with a new browser security feature. The Mixed Content Blocker is enabled by default in Firefox 23 and protects our users from man-in-the-middle attacks and eavesdroppers on HTTPS pages.

When an HTTPS page contains HTTP resources, the HTTP resources are called Mixed Content. With the latest Aurora, Firefox will block certain types of Mixed Content by default, providing a per-page option for users to “Disable Protection” and override the blocking.

What types of Mixed Content are blocked by default and what types are not? The browser security community has divided mixed content into two categories: Mixed Active Content (like scripts) and Mixed Passive Content (like images). Mixed Active Content is considered more dangerous than Mixed Passive Content because the former can alter the behavior of an HTTPS page and potentially steal sensitive data from users. Firefox 23+ will block Mixed Active Content by default, but allows Mixed Passive Content on HTTPS pages. For more information on the differences between Mixed Active and Mixed Passive Content, see here.

Mixed Content Blocker UI
Designing UI for security is always tricky. How do you inform the user about a potential security threat without annoying them and interrupting their task?

Larissa Co (@lyco1) from Mozilla’s User Experience team aimed to solve this problem. She created a Security UX Framework with a set of core principles that drove the UX design for the Mixed Content Blocker.

When a user visits an HTTPS page with blocked Mixed Active Content, they will see a shield icon in the location bar:

Clicking on the shield, the user will see options to “Learn More”, “Keep Blocking”, or “Disable Protection on This Page”:

If a user decides to “Keep Blocking”, the notification in the location bar will disappear:

If the user decides to Keep Blocking, the shield will disappear.

On the other hand, if a user decides to “Disable Protection on This Page”, all mixed content will load and the lock icon will be replaced with a yellow warning sign:

When a user visits an HTTPS page with Mixed Passive Content, Firefox will not block the passive content by default. But since the page is not fully encrypted, the user will not see the lock icon in the location bar:

Compatibility
We have a master tracking bug for websites that break when Mixed Active Content is blocked in Firefox 23+. In addition to websites that our users have been reporting to us, we are running automated tests on the Top Alexa websites looking for pages with Mixed Active Content. If you run into a compatibility issue with a website involving mixed content, please let us know in the master bug, or take a step further and contact the website to let them know. Chances are, their website is also broken on Chrome and/or Internet Explorer. Chrome and Internet Explorer also have Mixed Content Blockers, but their definitions of Mixed Active and Mixed Passive Content differ from slightly from Firefox’s definition.

Want to learn more?
Still curious and want to learn more details about the Mixed Content Blocker in Firefox? Check out this more detailed blog post or feel free to ask us questions on mozilla.dev.security.

Orangfuzz – an experimental user interaction fuzzer for Firefox OS

Apr 17 2013

Gary

One of the goals of the fuzzing team is to identify security vulnerabilities within our products using various techniques. As we continue working with Firefox OS, we need to build and adapt the proper tools to enable fuzz testing on the mobile device.

Orangfuzz is an experimental user interaction fuzzer. It builds on generate-orangutan-script.py and uses the Orangutan framework. Orangutan injects events directly into the low-level kernel device file that represents an Android device’s touch screen. It supports actions such as “tapping” and “dragging”, simulated from a user’s perspective. The fuzzer generates an Orangutan script containing random sets of these actions.

This concept was inspired by bug 838215, which was a crash involving the handling of touch events.

Orangfuzz currently only supports the B2G Test Driver device, but adding additional support for other devices, if Orangutan supports them, is straightforward. We define the device through its specifications (e.g. home key location, screen resolution). Adding support for additional devices is as simple as adding new subclasses which provide the appropriate resolution and screensizes. It may be possible to run this against the B2G emulators but this has not been tested.

Warning: It is entirely possible to generate a script that contains a set of actions that dial emergency numbers such as “911″, “112″ or “999″, so it is recommended to run the script against a special build of Gaia (not yet well-tested) with dialing and messaging capabilities disabled if one wants to run orangfuzz continuously without supervision.

How can you help?

Run orangfuzz on a test device.
Report bugs in Bugzilla when a generated script causes a crash in Firefox OS.

At this point we are still experimenting with the most effective strategy for identifying and triaging crashes, but please feel free to file bugs or ideas moving forward either on GitHub or in Bugzilla. Do subscribe to the mozilla.dev.b2g newsgroup if one is interested.

Bug 858174 tracks moving orangfuzz to production.

A demonstration video on YouTube with annotations is available, or you can get the .webm version (no audio).

-Gary Kwong

* Credits go out to Gregor Wagner, who wrote generate-orangutan-script.py, and William Lachance, author of the Orangutan framework.

We’re doing a Reddit AMA!

Mar 26 2013

Curtisk

Members of the Mozilla Security community will be participating in an “Ask Me Anything (AMA)” even on Reddit tomorrow, 27-March-2013. We anticipate to run this for 24 hours from March 27th at 6:00 am PDT through March 28th at 6:00 am PDT.

Within Mozilla our teams depend heavily on our community handle everything involved in Information Security research & development; if you would like to learn more please come out and ask us the questions you want to know the answer to!

You an also follow us on twitter at https://twitter.com/mozsec

This post will be updated with the appropriate links tomorrow morning.

Update:

Link to AMA: http://www.reddit.com/r/netsec/comments/1b3vcx/we_are_the_mozilla_security_community_ask_us/

Mozilla and Pwn2Own Event

Mar 7 2013

mcoates

This week the Pwn2Own competition took place as part of the CanSecWest security conference. The Pwn2Own competition provides cash rewards for individuals that are able to demonstrate a security vulnerability in browsers or the browser plugins Flash and Java.

Researchers successfully demonstrated new security vulnerabilities in all three browsers tested - Firefox, Chrome and IE. At the conclusion of the event we received technical details about the exploit so we could issue a fix.

We received the technical details on Wednesday evening and within less than 24 hours diagnosed the issue, built a patch, validated the fix and the resulting builds, and deployed the patch to users. Our fast turn around time on this security issue is a reflection of the priority and focus we place on security. Security is more than a side item for us, it’s part of our core principles.

We encourage community research within security and started the first major bug bounty program in 2004 for Firefox. Since then we’ve worked closely with experts around the world to help grow and mature security research. All security research and corresponding discoveries are used to proactively protect Firefox users as part of our larger security assurance program.

Find out more about how to get involved in Mozilla’s bug bounty program – http://www.mozilla.org/security/bug-bounty.html

Michael Coates
Director of Security Assurance

Announcing Version 2.1 of Mozilla CA Certificate Policy

Feb 15 2013

mcoates

Mozilla released version 2.1 of the Mozilla CA Certificate Policy. This version adds a requirement for either the technical constraint or the audit of subordinate CA certificates, and requires CAs who issue SSL certificates to comply with the CA/Browser Forum Baseline Requirements.

Mozilla is working towards stronger controls and visibility of publicly-trusted issuing certificates in order to make better trust decisions, detect security incidents faster, and limit the impact of each security incident. Version 2.1 of Mozilla’s CA Certificate Policy encourages CAs to technically constrain subordinate CA certificates using RFC 5280 extensions that are specified directly in the intermediate certificate and controlled by crypto code (e.g. NSS). We recognize that technically constraining subordinate CA certificates in this manner may not be practical in some cases, so the subordinate CA certificates may instead be publicly disclosed, and audited in accordance with Mozilla’s CA Certificate Policy.

All subordinate CA certificates that are issued after May 15, 2013 must comply with version 2.1 of Mozilla’s CA Certificate Policy, and all pre-existing subordinate CA certificates must be updated to comply with version 2.1 of Mozilla’s CA Certificate Policy for new certificate issuance by May 15, 2014. This time frame takes into account the impact that the new requirements might have on large enterprise subordinate CAs who may need to plan and budget for new infrastructure and audits.

Audit criteria have recently been released for the CA/Browser Forum’s “Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates” (BRs). Therefore, Version 2.1 of Mozilla’s CA Certificate Policy requires CAs to update their operations and SSL certificate issuance to comply with version 1.1 of the BRs. The BRs provide clear standards for CAs on important subjects including verification of identity, certificate content and profiles, CA security, revocation mechanisms, and use of algorithms and key sizes. As of February 2013, SSL certificate issuance must be audited according to the BR criteria, but initial BR audits for each CA and subCA that include a reasonable list of exceptions will be considered and potentially accepted.

Mozilla sent a CA Communication in January requesting that CAs review the draft of version 2.1 of Mozilla’s CA Certificate Policy and evaluate their current operations in regards to the Baseline Requirements. Responses to this communication are publicly posted and discussed in the mozilla.dev.security.policy forum. CAs are planning to complete their necessary system and documentation upgrades according to the grace periods that Mozilla provided. Many CAs continue to diligently work towards compliance with the BRs, the most common effort being to implement OCSP. Additionally, we asked CAs to scan their certificate databases to identify and revoke certificates that were not issued in accordance with certain recommended practices.

With these updates to Mozilla’s CA Certificate Policy, we re-iterate our belief that each root is ultimately accountable for every certificate it signs, directly or through its subordinates. Participation in Mozilla’s root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe, up to and including the removal of root certificates that mis-issue, as well as any roots that cross-sign them. Nevertheless, we believe that security is best served when browsers and CAs can work together; we hope that frank communication and clear expectations can resolve these issues before any such action is required. We must also be diligent in looking for new ways to improve the security systems of the web. Those systems are built on the trust of web users, and we all have a responsibility to be strong stewards of that trust.

Mozilla Security Team

Using CryptoStick as an HSM

Feb 13 2013

gdestuynder

Mozilla maintains a wide range of services which are secured using different solutions. For internal repositories, our Operations Security team has chosen to use the low-cost, open source and open hardware CryptoStick from the German Privacy Foundation.

Advantages of using an HSM
An HSM is a Hardware Security Module. It’s a hardware card, stick, device able to perform crypto operations. In general, it stores private keys which are used to sign, encrypt or authenticate.
The key itself never leaves the hardware, thus attackers cannot steal the key (i.e., if the hardware is disconnected, the key cannot be used anymore.)

Note: In the event the system is compromised, the connected key can still be used. Thus, the access to the system should be otherwise secured and the key should be removed when not in use.

Our use case
Internal package repositories, such as RPM or Deb. all use GnuPG for package signing.
Mozilla’s architecture is however broad and different teams use different platforms, at different places, in different networks.
We want to ensure that the packages they install are signed by us, and while we’re at it, have a good level of assurance that the key used for signing cannot be compromised or stolen.
We also need redundancy.

Many community-owned projects, such as Linux distributions have to deal with the exact same issue. Often, the signing machine has no HSM. This is one of the possible solutions.

About the CryptoStick
The choice was driven by:

The openness of the project
The size and connectivity (USB)
No real smart card, yet easy to physically disconnect
The integration with GnuPG (OpenPGP Smart card, ISO 7816-4)
Low price and ease of getting additional sticks
Speed, support and certifications were not a requirement

The major point being, that the CryptoStick operates without any smart card, but emulates one instead.

Note: while we focus here on using OpenPGP for signing, the stick also supports other standards, such as x509 certificates and SSH authentication.

Our setup
We use BL460c blade servers which have an internal USB port. Dimensions are perfect for the CryptoStick.

We have decided on having two repository machines for redundancy, signing with the same keys.
We also needed to be able to replace the hardware easily (both machines and the CryptoStick) in case of failure, which involves backing up the private key off-site. Finally, we needed the signing to happen automatically.

Some modifications were needed in order to make this work:

Custom PIN-entry program
As the OpenPGP smart card standard requires entering a user PIN upon signing, we needed this user PIN to be entered automatically. Consequently, we assume the user PIN adds no security in our setup.

A simple script is used as pinentry program: https://github.com/gdestuynder/pinentry-auto

Note: the non-enforcing user PIN option only allows for caching the user PIN upon successfully entering the user PIN a first time, which would defeat the purpose of automatic signing in case of system reboot, process restart, etc.

One private signing key, multiple sticks
The OpenPGP smart card standard also require the private keys generated on the HSM to contain the card’s serial number. While it allows for a software backup at creation time, the backup also contains the card’s serial number. The hardware will refuse to load those keys on a CryptoStick with a different serial number.

There is a different way to work around this issue. The stick also supports importing private keys. By using an offline machine, it is possible to generate the signing key in software using traditional GnuPG commands, and import it on the stick.
This allowed us to import the signing key on different sticks, and to keep an off-site backup.

This is also the most significant difference with traditional HSMs, which requires a set of smart cards to protect and import the key backup. In our use case, we decided that the trade-off was acceptable.

Note: when possible, it’s recommended to keep a master signing key offline, and create software signing GnuPG sub-keys. In the unlikely event of HSM compromise, it is then possible to revoke the sub-keys while retaining the trust of the master key, which then is simply used to issue new signing sub-keys. Not all package repositories support this feature.

Advanced usage, some commands
Here are some sample commands that are commonly used with the CryptoStick.

Note: it’s generally more convenient to have the gpg-agent running, for speed,and for PIN caching. General usage, such as encryption, signing and authentication work with the exact same commands as with a regular GnuPG or SSH key.

Get card info:
$ gpg –card-status

scdaemon[10692]: updating slot 0 status: 0x0000->0x0007 (0->1) Application ID ...: D2760001240102000005000014731337 Version ..........: 2.0 Manufacturer .....: ZeitControl Serial number ....: 00001478 Name of cardholder: Mozilla Language prefs ...: en Sex ..............: unspecified URL of public key : [not set] Login data .......: [not set] Signature PIN ....: [not set] Key attributes ...: 2048R 2048R 2048R Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 16 Signature key ....: 067A A494 9B64 347D FA2E EEEE 9B3C 64F9 8006 EEEE created ....: 2013-01-17 22:40:53 Encryption key....: 3C00 DA66 554D 67FE 8607 1AAB AAAA C9F2 AAAA 1D67 created ....: 2013-01-17 22:40:53 Authentication key: 1AF9 988A 0EAB 6F10 D69C 2DFC EF3B CCCC 784E A733 created ....: 2013-01-17 22:40:53 General key info..: [none]

Set User and Admin PIN. Defaults are 123456 and 12345678 respectively:
$ gpg --card-edit Command> admin Admin commands are allowed Command> passwd

Generate keys (you need to have setup the PINs above first):
$ gpg --card-edit Command> admin Admin commands are allowed Command> generate

Import existing key (only recommended if the original keys were generated on a trusted machine, such as an offline machine that has never been connected to the network):
Note: this will erase the key from disk during the import. If necessary, make an extra backup of the key first.

$ gpg --edit-key gpg> toggle gpg> keytocard (say yes) gpg> save gpg> quit

Reset to factory defaults:
Make sure GnuPG agent is started, if not:
$ eval $(gpg-agent --daemon)

Send the reset commands:
$ gpg-connect-agent < file

Where “file” contains:
hex scd serialno scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 e6 00 00 scd apdu 00 44 00 00 /echo Reset complete

Putting Users in Control of Plugins

Jan 29 2013

mcoates

Mozilla is changing the way Firefox loads third party plugins such as Flash, Java and Silverlight. This change will help increase Firefox performance and stability, and provide significant security benefits, while at the same time providing more control over plugins to our users.

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

Using Coverage Data for Security

Jan 22 2013

decoder

We recently started measuring C/C++ code coverage on mozilla-central again and documented the various efforts around it in a new MDN article. Continue reading …

Protecting Users Against Java Vulnerability

Jan 11 2013

mcoates

Update – January 18, 2013

Mozilla is extending Click to Play for Java 7u11 due to reports of exploit code available for 7u11 and information that all elements of the original Java bug have not been fully addressed by Oracle in the 7u11 patch.

Update – January 13, 2013

Oracle has released an update to address this vulnerability. Read more here and download updates here.

Issue

Mozilla is aware of a security vulnerability in the current version of Java (Java 7 Update 10) that is being actively exploited and affects any browser using the Java plugin. Firefox users may be vulnerable to this issue if they have the Java plugin installed in their browser. Information on how to check which plugins are installed can be found here.

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.

Status

~~There is no patch currently available for this issue from Oracle.~~ To protect Firefox users we have enabled Click To Play for recent versions of Java on all platforms (Java 7u9, 7u10, 6u37, 6u38). Firefox users with older versions of Java are already protected by existing plugin blocking or Click To Play defenses.

The Click To Play feature ensures that the Java plugin will not load unless a user specifically clicks to enable the plugin. This protects users against drive-by exploitation, one of the most common exploit techniques used to compromise vulnerable users. Click To Play also allows users to enable the Java plugin on a per-site basis if they absolutely need the Java plugin for the site.

Demo screenshot of Click To Play

Additional Information

We encourage users to always keep plugins up to date. Visit the plugin check website to update plugins now.

Information to fully disable the Java plugin can be found at the following page: http://support.mozilla.org/kb/How to turn off Java applets

Michael Coates
Director of Security Assurance

Revoking Trust in Two TurkTrust Certificates

Jan 3 2013

mcoates

Update: For clarification, the last sentence of this post references our actions to suspend inclusion of a TURKTRUST root certificate. There are currently two TURKTRUST root certificates included in Mozilla’s CA Certificate program. TURKTRUST had requested that a newer root certificate be included, and their request had been approved and was in Firefox 18 beta. However, due to the mis-issued intermediate certificates, we decided to suspend inclusion of their new root certificate for now.

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