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!

Mitigating Logjam: Enforcing Stronger Diffie-Hellman Key Exchange

David Keeler

In response to recent developments attacking Diffie-Hellman key exchange (https://weakdh.org/) and to protect the privacy of Firefox users, we have increased the minimum key size for TLS handshakes using Diffie-Hellman key exchange to 1023 bits. A small number of servers are not configured to use strong enough keys. If a user attempts to connect to such a server, they will encounter the error “ssl_error_weak_server_ephemeral_dh_key”.

Update 2016-10-03: this was accidentally re-published on September 30, 2016. There has been no change to the minimum accepted Diffie-Hellman key size since this mid-2015 announcement.

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/

Changes to the Firefox Bug Bounty Program

rforbes@mozilla.com

The Bug Bounty Program is an important part of security here at Mozilla.  This program has paid out close to 1.6 million dollars to date and we are very happy with the success of it.  We have a great community of researchers who have really contributed to the security of Firefox and our other products.

Those of us on the Bug Bounty Committee did an evaluation of the Firefox bug bounty program as it stands and decided it was time for a change.

First, we looked at how much we award for a vulnerability.  The amount awarded was increased to $3000 five years ago and it is definitely time for this to be increased again.  We have dramatically increased the amount of money that a vulnerability is worth.  On top of that, we took a look at how we decided how much we should pay out.  Rather than just one amount that can be awarded, we are moving to a variable payout based on the quality of the bug report, the severity of the bug, and how clearly the vulnerability can be exploited.

Finally, we looked into how we decide what vulnerability is worth a bounty award.  Historically we would award $3000 for vulnerabilities rated Critical and High.  Issues would come up where a vulnerability was interesting but was ultimately rated as Moderate.  From now on, we will officially be paying out on Moderate rated vulnerabilities.  The amount that is paid out will be determined by the committee, but the general range is $500 to $2000.  This doesn’t mean that all Moderate vulnerabilities will be awarded a bounty but some will.

All of these changes can be found on our website here: here

Another exciting announcement to make is the official release of our Firefox Security Bug Bounty Hall of Fame!  This page has been up for a while but we haven’t announced it until now.  This is a great place to find your name if you are a researcher who has found a vulnerability or if you want to see all the people who have helped make Firefox so secure.

We will be making a Web and Services Bug Bounty Hall of Fame page very soon. Keep an eye out for that!

https://www.mozilla.org/en-US/security/bug-bounty/hall-of-fame/

Feel free to mail us at security@mozilla.com with any questions!

MozDef: The Mozilla Defense Platform v1.9

Jeff Bryner

1 response

At Mozilla we’ve been using The Mozilla Defense Platform (lovingly referred to as MozDef) for almost two years now and we are happy to release v1.9. If you are unfamiliar, MozDef is a Security Information and Event Management (SIEM) overlay for ElasticSearch.

MozDef aims to bring real-time incident response and investigation to the defensive tool kits of security operations groups in the same way that Metasploit, LAIR and Armitage have revolutionized the capabilities of attackers.

We use MozDef to ingest security events, alert us to security issues, investigate suspicious activities, handle security incidents and to visualize and categorize threat actors. The real-time capabilities allow our security personnel all over the world to work collaboratively even though we may not sit in the same room together and see changes as they occur. The integration plugins allow us to have the system automatically respond to attacks in a preplanned fashion to mitigate threats as they occur.

We’ve been on a monthly release cycle since the launch, adding features and squashing bugs as we find them. You can find the release notes for this version here.

Notable changes include:

  •  Support for Google API logs (login/logout/suspicious activity for Google Drive/Docs)
  •  http://cymon.io api integration
  •  myo armband integration

Using the Myo armband in a TLS environment may require some tweaking to allow the browser to connect to the local Myo agent. Here’s a quick config for proxying via nginx. Check out the docs for other tips.

Feel free to take it for a spin on the demo site. You can login by creating any test email/password combination you like. The demo site is rebuilt occasionally so don’t expect anything you put there to live for more than a couple days but feel free to test it out.

Development for the project takes place at mozdef.com and report any issues using the github issue tracker.

May 2015 CA Communication

Kathleen Wilson

1 response

Mozilla has sent a Communication to the Certification Authorities (CAs) who have root certificates included in Mozilla’s program. Mozilla’s CA Certificate Program governs inclusion of root certificates in Network Security Services (NSS), a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The NSS root certificate store is not only used in Mozilla products such as the Firefox browser, but is also used by other companies in a variety of applications.

The CA Communication has been emailed to the Primary Point of Contact (POC) for each CA in Mozilla’s program, and they have been asked to respond to 5 action items:

  1. Confirm that they are the current Primary POC, or give alternative details;
  2. Confirm that Mozilla has the correct link to their most recent Baseline Requirements audit statement;
  3. Update us on their progress in eliminating use of SHA-1 as a certificate signature algorithm;
  4. Inform us whether they are still issuing certificates with certain problems identified when we moved to mozilla::pkix; and
  5. Tell us about their support for IPv6.

The full action items can be read here. Responses to the survey will be collated using Salesforce and the answers published in June.

With this CA Communication, we re-iterate that participation in Mozilla’s CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve.

Mozilla Security Team

Deprecating Non-Secure HTTP

Richard Barnes

288 responses

Today we are announcing our intent to phase out non-secure HTTP.

There’s pretty broad agreement that HTTPS is the way forward for the web.  In recent months, there have been statements from IETF, IAB (even the other IAB), W3C, and the US Government calling for universal use of encryption by Internet applications, which in the case of the web means HTTPS.

After a robust discussion on our community mailing list, Mozilla is committing to focus new development efforts on the secure web, and start removing capabilities from the non-secure web.  There are two broad elements of this plan:

  1. Setting a date after which all new features will be available only to secure websites
  2. Gradually phasing out access to browser features for non-secure websites, especially features that pose risks to users’ security and privacy.

For the first of these steps, the community will need to agree on a date, and a definition for what features are considered “new”.  For example, one definition of “new” could be “features that cannot be polyfilled”.  That would allow things like CSS and other rendering features to still be used by insecure websites, since the page can draw effects on its own (e.g., using <canvas>).  But it would still restrict qualitatively new features, such as access to new hardware capabilities.

The second element of the plan will need to be driven by trade-offs between security and web compatibility.  Removing features from the non-secure web will likely cause some sites to break.  So we will have to monitor the degree of breakage and balance it with the security benefit.  We’re also already considering softer limitations that can be placed on features when used by non-secure sites.  For example, Firefox already prevents persistent permissions for camera and microphone access when invoked from a non-secure website.  There have also been some proposals to limit the scope of non-secure cookies.

It should be noted that this plan still allows for usage of the “http” URI scheme in legacy content. With HSTS and the upgrade-insecure-requests CSP attribute, the “http” scheme can be automatically translated to “https” by the browser, and thus run securely.

Since the goal of this effort is to send a message to the web developer community that they need to be secure, our work here will be most effective if coordinated across the web community.  We expect to be making some proposals to the W3C WebAppSec Working Group soon.

Thanks to the many people who participated in the mailing list discussion of this proposal.  Let’s get the web secured!

Richard Barnes, Firefox Security Lead

Update (2015-05-01): Since there are some common threads in the comments, we’ve put together a FAQ document with thoughts on free certificates, self-signed certificates, and more.

Removing e-Guven CA Certificate

Kathleen Wilson

3 responses

The Certification Authority (CA) certificate owned by e-Guven Elektronik Bilgi Guvenligi A.S. will be removed in Firefox 38 due to insufficient and outdated audits.

The integrity of the secure Web depends on CAs issuing certificates that correctly attest to the identity of websites. Mozilla products ship a default list of CA certificates, which may change with each security patch or new version of the product. Inclusion of a CA certificate in Mozilla products involves a rigorous process and evaluation of the CA’s public-facing policy documentation and audit statements, in order to verify that the CA conforms to the criteria required by Mozilla’s CA Certificate Inclusion Policy.

The CA certificates included in the Mozilla list can be marked as trusted for various purposes, so that the software can use the CA certificates to verify certificates for (1) SSL/TLS servers, (2) S/MIME email users, and/or (3) digitally-signed code objects, without having to ask users for further permission or information. When a CA certificate is trusted for verifying certificates for SSL/TLS servers, Mozilla’s CA Certificate Inclusion Policy requires CAs to annually provide public-facing attestation from an independent party stating that they have audited the CA using one of the following two sets of criteria:

1) Clause 7, “Requirements on CA practice”, in ETSI TS 102 042 V2.3.1 or later version, Policy requirements for certification authorities issuing public key certificates (as applicable to the “EVCP” and “EVCP+” certificate policies, DVCP and OVCP certificate policies for publicly trusted certificates – baseline requirements, and any of the “NCP”, “NCP+”, or “LCP” certificate policies);
OR
2) WebTrust “Principles and Criteria for Certification Authorities 2.0″ or later and “SSL Baseline Requirements Audit Criteria V1.1” (as applicable to SSL certificate issuance) in WebTrust Program for Certification Authorities

Despite many requests for E-Guven to provide current public-facing audit statements that meet the requirements of Mozilla’s CA Certificate Inclusion Policy, the audit statement that Mozilla has for E-Guven indicates that the last supervision of E-Guven was held in 2013 and was not performed according to either of the above sets of criteria. Therefore, discussion about this CA was held in the mozilla.dev.security.policy forum, and the consensus was that E-Guven’s root certificate should be removed.

As always, we recommend that all users upgrade to the latest version of Firefox. This particular change will be in Firefox 38 and future releases of Firefox.

Mozilla Security Team