Man-in-the-Middle Interfering with Increased Security

Richard Barnes

According to the plan we published earlier for deprecating SHA-1, on January 1, 2016, Firefox 43 began rejecting new certificates signed with the SHA-1 digest algorithm.  For Firefox users with unfiltered access to the Internet, this change probably went unnoticed, since there simply aren’t that many new SHA-1 certs being used.  However, for Firefox users who are behind certain “man-in-the-middle” devices (including some security scanners and antivirus products), this change removed their ability to access HTTPS web sites.  When a user tries to connect to an HTTPS site, the man-in-the-middle device sends Firefox a new SHA-1 certificate instead of the server’s real certificate.  Since Firefox rejects new SHA-1 certificates, it can’t connect to the server.

How to tell if you’re affected

If you can access this article in Firefox, you’re fine.  If you’re reading this in another browser, see if you can load the security blog (or any other HTTPS link) in Firefox.  Click “Advanced”, and if you see the error code “SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED”, then you’re affected.

What to do if you’re affected

The easiest thing to do is to install the newest version of Firefox.  You will need to do this manually, using an unaffected copy of Firefox or a different browser, since we only provide Firefox updates over HTTPS.

If you want to avoid reinstalling, advanced users can fix their local copy of Firefox by going to about:config and changing the value of “security.pki.sha1_enforcement_level” to 0 (which will accept all SHA-1 certificates).

You should also make sure that any systems you have that might be doing man-in-the-middle are up to date, for example, some anti-virus software or security scanning devices.  Some vendors have removed the use of SHA-1 in recent updates.

Commitment to deprecate SHA-1

We are still committed to removing support for SHA-1 certificates from Firefox.  The latest version of Firefox re-enables support for SHA-1 certificates to ensure that we can get updates to users behind man-in-the-middle devices, and enable us to better evaluate how many users might be affected.  Vendors of TLS man-in-the-middle systems should be working to update their products to use newer digest algorithms.

Improving Revocation: OCSP Must-Staple and Short-lived Certificates

Mark Goodwin

Last year, we laid out a long-range plan for improving revocation support for Firefox. As of this week, we’ve completed most of the major elements of that plan. After adding OneCRL earlier this year, we have recently added support for OCSP Must-Staple and short-lived certificates. Together, these changes enable website owners several ways to achieve fast, secure certificate revocation.

In an ideal world, the browser would perform an online status check (such as OCSP) whenever it verifies a certificate, and reject the certificate if the check failed. However, these checks can be slow and unreliable. They time out about 15% of the time, and take about 350ms even when they succeed. Browsers generally soft-fail on revocation in an attempt to balance these concerns.

To get back to stronger revocation checking, we have added support for short-lived certificates and Must-Staple to let sites opt in to hard failures. As of Firefox 41, Firefox will not do “live” OCSP queries for sufficiently short-lived certs (with a lifetime shorter than the value set in “security.pki.cert_short_lifetime_in_days”). Instead, Firefox will just assume the certificate is valid. There is currently no default threshold set, so users need to configure it. We are collecting telemetry on certificate lifetimes, and expect to set the threshold somewhere around the maximum OCSP response lifetime specfied in the baseline requirements.

OCSP Must-Staple makes use of the recently specified TLS Feature Extension. When a CA adds this extension to a certificate, it requires your browser to ensure a stapled OCSP response is present in the TLS handshake. If an OCSP response is not present, the connection will fail and Firefox will display a non-overridable error page. This feature will be included in Firefox 45, currently scheduled to be released in March 2016.

Updated Firefox Security Indicators

Tanvi Vyas

This article has been coauthored by Aislinn Grigas, Senior Interaction Designer, Firefox Desktop

Over the past few months, Mozilla has been improving the user experience of our privacy and security features in Firefox. One specific initiative has focused on the feedback shown in our address bar around a site’s security. The major changes are highlighted below along with the rationale behind each change.

Change to DV Certificate treatment in the address bar

Color and iconography is commonly used today to communicate to users when a site is secure. The most widely used patterns are coloring a lock icon and parts of the address bar green. This treatment has a straightforward rationale given green = good in most cultures. Firefox has historically used two different color treatments for the lock icon – a gray lock for Domain-validated (DV) certificates and a green lock for Extended Validation (EV) certificates. The average user is likely not going to understand this color distinction between EV and DV certificates. The overarching message we want users to take from both certificate states is that their connection to the site is secure. We’re therefore updating the color of the lock when a DV certificate is used to match that of an EV certificate.

Although the same green icon will be used, the UI for a site using EV certificates will continue to differ from a site using a DV certificate. Specifically, EV certificates are used when Certificate Authorities (CA) verify the owner of a domain. Hence, we will continue to include the organization name verified by the CA in the address bar.

Changes to Mixed Content Blocker UI on HTTPS sites

A second change we’re introducing addresses what happens when a page served over a secure connection contains Mixed Content. Firefox’s Mixed Content Blocker proactively blocks Mixed Active Content by default. Users historically saw a shield icon when Mixed Active Content was blocked and were given the option to disable the protection.

Since the Mixed Content state is closely tied to site security, the information should be communicated in one place instead of having two separate icons. Moreover, we have seen that the number of times users override mixed content protection is slim, and hence the need for dedicated mixed content iconography is diminishing. Firefox is also using the shield icon for another feature in Private Browsing Mode and we want to avoid making the iconography ambiguous.

The updated design that ships with Firefox 42 combines the lock icon with a warning sign which represents Mixed Content. When Firefox blocks Mixed Active Content, we retain the green lock since the HTTP content is blocked and hence the site remains secure.

For users who want to learn more about a site’s security state, we have added an informational panel to further explain differences in page security. This panel appears anytime a user clicks on the lock icon in the address bar.

Previously users could click on the shield icon in the rare case they needed to override mixed content protection. With this new UI, users can still do this by clicking the arrow icon to expose more information about the site security, along with a disable protection button.

mixed active content click and subpanel

Users can click the lock with warning icon and proceed to disable Mixed Content Protection.

Loading Mixed Passive Content on HTTPS sites

There is a second category of Mixed Content called Mixed Passive Content. Firefox does not block Mixed Passive Content by default. However, when it is loaded on an HTTPS page, we let the user know with iconography and text. In previous versions of Firefox, we used a gray warning sign to reflect this case.

We have updated this iconography in Firefox 42 to a gray lock with a yellow warning sign. We degrade the lock from green to gray to emphasize that the site is no longer completely secure. In addition, we use a vibrant color for the warning icon to amplify that there is something wrong with the security state of the page.

We also use this iconography when the certificate or TLS connection used by the website relies on deprecated cryptographic algorithms.

The above changes will be rolled out in Firefox 42. Overall, the design improvements make it simpler for our users to understand whether or not their interactions with a site are secure.

Firefox Mobile

We have made similar changes to the site security indicators in Firefox for Android, which you can learn more about here.

Continuing to Phase Out SHA-1 Certificates

Richard Barnes

In our previous blog post about phasing out certificates with SHA-1 based signature algorithms, we said that we planned to take a few actions with regard to SHA-1 certificates:

  1. Add a security warning to the Web Console to remind developers that they should not be using a SHA-1 based certificates
  2. Show the “Untrusted Connection” error whenever a SHA-1 certificate issued after January 1, 2016, is encountered in Firefox
  3. Show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017

We have completed the first two of these steps.  We added the security warning to the Web Console in Firefox 38. If you open the Web Console and browse to a website with an SSL certificate that is SHA-1 based or is signed by a SHA-1 based intermediate certificate, you will get the following message in the console:

This site makes use of a SHA-1 Certificate; it’s recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1. [Learn More]

In Firefox 43 we plan to show an overridable “Untrusted Connection” error whenever Firefox encounters a SHA-1 based certificate that has ValidFrom after Jan 1, 2016. This includes the web server certificate as well as any intermediate certificates that it chains up to. Root certificates are trusted by virtue of their inclusion in Firefox, so it does not matter how they are signed. However, it does matter what hash algorithm is used in the intermediate signatures, so the rules about phasing out SHA-1 certificates applies to both the web server certificate and the intermediate certificates that sign it.

We are re-evaluating when we should start rejecting all SHA-1 SSL certificates (regardless of when they were issued).  As we said before, the current plan is to make this change on January 1, 2017.  However, in light of recent attacks on SHA-1, we are also considering the feasibility of having a cut-off date as early as July 1, 2016.

We do not currently plan to display an error if an OCSP response is signed by a SHA-1 certificate. According to section 7.1.3 of version 1.3 of the CA/Browser Forum Baseline Requirements: “CAs MAY continue to sign certificates to verify OCSP responses using SHA1 until 1 January 2017.” Additionally, we do not currently plan to throw an error when SHA-1 S/MIME and client authentication certificates are encountered.

Questions about SHA-1 based certificates should be directed to the mozilla.dev.security.policy forum.

Deprecating the RC4 Cipher

April King

As part of our commitment to protect the privacy of our users, Mozilla will disable the insecure RC4 cipher in Firefox in late January 2016, beginning with Firefox 44. Mozilla will be taking this action in coordination with the Chrome and IE/Edge teams. If you’re a web site operator and still rely on RC4, you need to enable some other ciphers, or Firefox users will be unable to reach you.  Very few servers rely exclusively on RC4, so most users should experience minimal disruption.

The Rise and Gradual Fall of RC4

Developed in 1987 by Ron Rivest, the RC4 cipher has been a staple of cryptography for almost 30 years.  For many years, RC4 was widely used by HTTPS servers: first because it was faster than contemporary alternatives, and later because it was immune to attacks that other ciphers were vulnerable to, such as BEAST.

Over the years, however, cryptanalysis of RC4 has resulted in better and better attacks against it.  It has been known since 1995 that RC4 has certain biases that make it easier to attack.  Recently, several practical attacks against RC4-protected HTTPS sessions have been demonstrated.  This led the IETF to publish RFC 7465, which forbids the use of RC4 in TLS.

At the same time, newer ciphers such as AES-GCM have been created, which are as fast as RC4 on modern hardware, and are also immune to attacks such as BEAST.  Most web servers support these newer ciphers, and the majority of Firefox TLS transactions already use them.

Deprecation of RC4 in Firefox

Until recently, RC4 was fully supported by Firefox to maintain compatibility with older servers, but over the past year, we’ve been gradually removing support.

In Firefox 36 (released in February 2015), we took the first step by making RC4 a “fallback-only” cipher.  With that change, Firefox would first try to communicate with the server using secure ciphers, before “falling back” to RC4.  As a result, Firefox would only use RC4 if the server didn’t support anything better.  That was a major step; over the course of the following weeks, RC4 usage by Firefox dropped from around 27% of TLS transactions to less than 0.5%.

In Firefox 38 (released in May 2015), we took a further step by disabling RC4 almost entirely in our pre-release Nightly and Developer Edition products, leaving it enabled only for a small whitelist of sites.  Web developers using those products to test their sites will have already seen breakage if their site requires RC4.  Perhaps as a result of this, RC4 usage by Firefox has continued to gradually decline, to the point where it’s currently used in only 0.08% of TLS transactions.

Disabling RC4 by Default

RC4 will no longer be offered by default in TLS fallback beginning with Firefox 44, set to be released on January 26, 2016. As a result, Firefox will refuse to negotiate RC4 with web servers. We are announcing this change now in order to provide website operators with time to update their websites.

As noted above, the share of Firefox TLS communications using RC4 has fallen from approximately 27% at the end of 2014 to only .08% at present.  As such, Mozilla expects the impact from this change to be minimal and localized to a small number of websites that currently only offer RC4 and are unable to upgrade prior to January.

Mozilla maintains a set of guidelines on TLS configurations and a TLS configuration generator to assist website operators in the selecting a secure configuration for their websites. Although it is recommended that website operators remove the availability of RC4 entirely, those that require compatibility with older clients such as Internet Explorer 6 may want to continue to offer RC4.  As long as more modern ciphers suites containing AES are also available, Firefox will use those more secure options instead of RC4.

Users that would like to disable RC4 fallback prior to the January release may set the security.tls.unrestricted_rc4_fallback setting inside of about:config to false.  After that preference is set to false by default in Firefox 44, users that still require RC4 may re-enable it by setting it back to true.

Improving Security for Bugzilla

Richard Barnes

The Bugzilla bug tracker is a major part of how we accomplish our mission of openness at Mozilla. It’s a tool for coordinating among our many contributors, and a focal point for community interactions. While most information in Bugzilla is public, Bugzilla restricts access to security-sensitive information, so that only certain privileged users can access it.

It is in the same spirit of openness that we are disclosing today that someone was able to steal security-sensitive information from Bugzilla.  We believe they used that information to attack Firefox users. Mozilla has conducted an investigation of this unauthorized access, and we have taken several actions to address the immediate threat.  We are also making improvements to Bugzilla to ensure the security of our products, our developer community, and our users.

The account that the attacker broke into was shut down shortly after Mozilla discovered that it had been compromised.  We believe that the attacker used information from Bugzilla to exploit the vulnerability we patched on August 6.  We have no indication that any other information obtained by the attacker has been used against Firefox users.  The version of Firefox released on August 27 fixed all of the vulnerabilities that the attacker learned about and could have used to harm Firefox users.

We are updating Bugzilla’s security practices to reduce the risk of future attacks of this type. As an immediate first step, all users with access to security-sensitive information have been required to change their passwords and use two-factor authentication. We are reducing the number of users with privileged access and limiting what each privileged user can do. In other words, we are making it harder for an attacker to break in, providing fewer opportunities to break in, and reducing the amount of information an attacker can get by breaking in.

Openness, transparency, and security are all central to the Mozilla mission. That’s why we publish security bugs once they’re no longer dangerous, and it’s why we’re writing a blog post about unauthorized access to our infrastructure. We have notified the relevant law enforcement authorities about this incident, and may take additional steps based on the results of any further investigations.

For more details, please see our FAQ document.

Expanded Malware Protection in Firefox

Francois Marier

As part of our commitment to help Firefox users stay safe online, we have recently expanded the malware detection features in Firefox. Thanks to new developments in Google’s Safe Browsing service we are now able to identify malware downloads in all of our supported platforms as well as warn users about potentially unwanted software.

The first of these changes, introduced in Firefox 39, consists of extending the monitoring of malicious file downloads to the Mac and Linux versions of Firefox.

When downloading a file of a type that usually contains Windows or Mac executable code (for example, .com, .exe, .msi, .app, .dmg) Firefox asks Google’s Safe Browsing service if the file is safe by sending it some of the download’s metadata (file type, name, size, hash, URL, locale). If the file is flagged as harmful by this service, the download manager will block access to the file until the user performs a right-click, and unblocks it manually.

In addition to this, Firefox 40 now issues a warning if you visit a page known to contain deceptive software that can make undesirable changes to your computer. You will be presented with the following warning if you encounter such a page:

Interstitial warning page when navigating to a site containing potentially unwanted software

While we believe that malware protection is in the best interest of all of our users, we recognize that some will prefer not to send any data about downloaded files to Google and hence provide an easy way to disable this feature.

Firefox exploit found in the wild

Daniel Veditz

224 responses

Yesterday morning, August 5, a Firefox user informed us that an advertisement on a news site in Russia was serving a Firefox exploit that searched for sensitive files and uploaded them to a server that appears to be in Ukraine. This morning Mozilla released security updates that fix the vulnerability. All Firefox users are urged to update to Firefox 39.0.3. The fix has also been shipped in Firefox ESR 38.1.1.

The vulnerability comes from the interaction of the mechanism that enforces JavaScript context separation (the “same origin policy”) and Firefox’s PDF Viewer. Mozilla products that don’t contain the PDF Viewer, such as Firefox for Android, are not vulnerable. The vulnerability does not enable the execution of arbitrary code but the exploit was able to inject a JavaScript payload into the local file context. This allowed it to search for and upload potentially sensitive local files.

The files it was looking for were surprisingly developer focused for an exploit launched on a general audience news site, though of course we don’t know where else the malicious ad might have been deployed. On Windows the exploit looked for subversion, s3browser, and Filezilla configurations files, .purple and Psi+ account information, and site configuration files from eight different popular FTP clients. On Linux the exploit goes after the usual global configuration files like /etc/passwd, and then in all the user directories it can access it looks for .bash_history, .mysql_history, .pgsql_history, .ssh configuration files and keys, configuration files for remina, Filezilla, and Psi+, text files with “pass” and “access” in the names, and any shell scripts. Mac users are not targeted by this particular exploit but would not be immune should someone create a different payload. [Update: we’ve now seen variants that do have a Mac section, looking for much the same kinds of files as on Linux.]

The exploit leaves no trace it has been run on the local machine. If you use Firefox on Windows or Linux it would be prudent to change any passwords and keys found in the above-mentioned files if you use the associated programs. People who use ad-blocking software may have been protected from this exploit depending on the software and specific filters being used.

Mozilla Winter of Security is back!

Julien Vehent

2 responses

mwos_logo_simple_transparentLast year, we introduced the Mozilla Winter of Security (MWoS) to invite students to work on security projects with members of Mozilla’s security teams. Ten projects were proposed, and dozens of teams applied. A winter later, MWoS 2014 gave birth to exciting new technologies such as the SeaSponge Threat Modeling platform, the Masche memory scanning Go library, a Linux Audit plugin written in Go for integration in Heka, and a TLS Observatory.

The first edition of MWoS was a success, and a lot of fun for students and mentors, so we decided to run it again this year. For the 2015 edition, we are proposing six projects that directly contribute to our most impactful security tools. Students will be able to work on digital forensics with MIG, SSL/TLS configurations with Menagerie, certificate management with LetsEncrypt, security visualization with MozDef, and web security scanning with OWASP ZAP.

The feedback from last year taught us that students work better when their mentors are more available to support them. But time is a scarce resource, and mentors can be hard to reach. This year we decided to reduce the number of projects and give each project two mentors: a primary and a secondary. Mentors also have a maximum of one project as primary, which will help dedicate more attention to the students. Our goal is to provide as much support as we can and help the teams succeed.

For students the requirements are unchanged: teams must be engaged in a university program and their professor must agree to give them credits for their MWoS project. Based on last year’s feedback, this formula works very well to ensure students have the time and motivation to work on their project.

Head over to the wiki for the detailed list of projects and application details: https://wiki.mozilla.org/Security/Automation/Winter_Of_Security_2015

Applications open today and will close on August 15th, in just one month! If you are a professor, tell your students about MWoS today. If you are a student, start assembling your team, and fill up the application form before August 15th. We will take about two weeks after the applications close to contact the teams and let them know if they have been selected.

Questions about the MWoS program or the projects can be directed to the mentors directly by email or on the #security IRC channel.

Come join us, we have t-shirts!

Dharma

Christoph Diehl


dharma

As soon as a developer at Mozilla starts integrating a new WebAPI feature, the Mozilla Security team begins working to help secure that API. Subtle programming mistakes in new code can introduce annoying crashes and even serious security vulnerabilities that can be triggered by malformed input which can lead to headaches for the user and security exposure.

WebAPIs start life as a specification in the form of an Interface Description Language, or IDL. Since this is essentially a grammar, a grammar-based fuzzer becomes a valuable tool in finding security issues in new WebAPIs because it ensures that expected semantics are followed most of the time, while still exploring enough undefined behavior to produce interesting results.

We came across a grammar fuzzer Ben Hawkes released in 2011 called “Dharma.” Sadly, only one version was ever made public. We liked Ben’s approach, but Dharma was missing some features which were important for us and its wider use for API fuzzing. We decided to sit down with our fuzzing mates at BlackBerry and rebuild Dharma, giving the results back to the public, open source and licensed as MPL v2.

We redesigned how Dharma parses grammars and optimized the speed of parsing and the generating of fuzzed output, added new grammar features to the grammar specification, added support for serving testcases over a WebSocket server, and made it Python 3 ready. It comes with no dependencies and runs out of the box.

In theory Dharma can be used with any data that can be represented as a grammar. At Mozilla we typically use it for APIs like WebRTC, WebAudio, or WebCrypto.


dharma_demo

Dharma has no integrated harness. Feel free to check out the Quokka project which provides an easy way for launching a target with Dharma, monitoring the process and bucketing any faults.

Dharma is actively in use and maintained at Mozilla and more features are planned for the future. Ideas for improvements are always greatly welcomed.

Dharma is available via GitHub (preferred and always up-to-date) or via PyPi by running “pip install dharma”.

References
– https://github.com/mozillasecurity/dharma
– https://github.com/mozillasecurity/quokka
– https://code.google.com/p/dharma/