Update on reviewing our data practices and Bugzilla development database disclosure

jstevensen

2

As we indicated in the post titled “MDN Disclosure”, we began several remediation measures, including a review of data practices surrounding user data. We have kicked off a larger project to better our practices around data, including with respect to the various non-Mozilla projects we support. We are implementing immediate fixes for any discovered issues across the organization, and are requiring each business unit to perform a review of their data practices and, if necessary, to implement additional protections based on that review.

As we proceed through our broader remediation program, we discovered an incident that occurred in the Bugzilla community, one of the community projects we support. A member of the Bugzilla community discovered that development database dump files containing email addresses and encrypted passwords were posted on a publicly accessible server. They were alerted to this incident by a security bug filed by a contributor. See the Bugzilla community blog post for more information.

While it is important to note that the disclosure of this development database does not affect bugzilla.mozilla.org, we continue to believe that the broader community would benefit from our increased focus on data practices and therefore will continue with our plan of including the Bugzilla project as well as other community projects in the data practices initiatives we’ve described above.

We are committed to continuing to improve our data practices to minimize the likelihood of these and other types of incidents.

Sincerely,

Mozilla Security

mozilla::pkix ships in Firefox!

dkeeler

In April, we announced an upcoming certificate verification library designed from the ground up to be fast and secure. A few weeks ago, this new library – known as “mozilla::pkix” – shipped with Firefox and is enabled by default. Please see the original announcement for more details.
Along with using more verifiably secure coding practices, we took the opportunity to closely adhere to the X.509 certificate verification specifications for the Internet. For example, we prevent certificates from being misused in ways that legacy libraries often do not. This protects user data and promotes an overall more secure Web.
However, this sometimes comes at a compatibility cost. Some certificates issued by certificate authorities not in Mozilla’s Root CA program may no longer work in the same way. We are currently evaluating how we can best balance security with usability with regard to these certificates.
If you encounter compatibility issues, please read the Certificate Primer which contains information for creating a compatible certificate hierarchy.

MDN Database Disclosure

Stormy

116

We have just concluded an investigation into a disclosure affecting members of Mozilla Developer Network. We began investigating the incident as soon as we learned of the disclosure. The issue came to light ten days ago when one of our web developers discovered that, starting on about June 23, for a period of 30 days, a data sanitization process of the Mozilla Developer Network (MDN) site database had been failing, resulting in the accidental disclosure of MDN email addresses of about 76,000 users and encrypted passwords of about 4,000 users on a publicly accessible server. As soon as we learned of it, the database dump file was removed from the server immediately, and the process that generates the dump was disabled to prevent further disclosure. While we have not been able to detect malicious activity on that server, we cannot be sure there wasn’t any such access.

We are known for our commitment to privacy and security, and we are deeply sorry for any inconvenience or concern this incident may cause you.

The encrypted passwords were salted hashes and they by themselves cannot be used to authenticate with the MDN website today. Still, it is possible that some MDN users could have reused their original MDN passwords on other non-Mozilla websites or authentication systems. We’ve sent notices to the users who were affected. For those that had both email and encrypted passwords disclosed, we recommended that they change any similar passwords they may be using.

In addition to notifying users and recommending short term fixes, we’re also taking a look at the processes and principles that are in place that may be made better to reduce the likelihood of something like this happening again. If you have questions, please reach out to security@mozilla.org.

Thanks,

Stormy Peters
Director of Developer Relations

Joe Stevensen
Operations Security Manager

Improving Malware Detection in Firefox

Sid Stamm

14

We are always looking for ways to help protect people better from the constant threat of malicious software. For years Firefox has utilized Google’s Safe Browsing phishing and malware protection to help keep you from accidentally visiting dangerous sites. This protection feature works by checking the sites that you visit against lists that Firefox downloads of reported phishing and malware sites. (For more details, check out this page.)

Firefox is about to get safer.

Until recently, we only had access to lists of reported malicious web sites, now the Safe Browsing service monitors malicious downloaded files too. The latest version of Firefox (as of July 22) will protect you from more malware by comparing files you download against these lists of malicious files, and blocking them from infecting your system.

The next version of Firefox (released in September) will prevent even more malicious downloads on Windows. When you download an application file, Firefox will verify the signature. If it is signed, Firefox then compares the signature with a list of known safe publishers. For files that are not identified by the lists as “safe” (allowed) or as “malware” (blocked), Firefox asks Google’s Safe Browsing service if the software is safe by sending it some of the download’s metadata. Note this online check will only be performed in Firefox on Windows for those downloaded files that don’t have a known good publisher. Most of the common and safe software for Windows is signed and so this final check won’t always need to happen.

In our preliminary testing, we estimate this new malware protection cuts the amount of malware that slips through Firefox’s protections in half. That’s a lot of malware that will be stopped in its tracks.

And of course if you don’t want to send Google data about the few downloads that don’t match these lists, you can turn off malware protection. But we believe eradicating malware is critical for most people, and expect this new feature to help work behind the scenes to keep you safe as you browse.

For more details, head on over to Monica’s blog post.

June is Internet Safety Month!

Sid Stamm

Happy Internet Safety Month, everyone!

In today’s world it is more critical than ever to be aware of security risks online. High-profile and broad attacks made news quite a bit in the last year. From the Heartbleed vulnerability to spikes in credit card theft and fraud, buzz about online privacy and security is on the rise. Even the White House has turned attention to cybersecurity.

The Ponemon Institute estimates 47% of Americans have had their personal information compromised! So now is a great time to do some routine maintenance this month and beef up your safety:

  1. Download a secure and private browser: A Web browser like Mozilla Firefox supports phishing and malware detection and protection from spyware, and also warns you about potentially fraudulent sites. Additionally, Firefox and most other Web browsers offer a “Do Not Track” feature that lets you opt to not have your information tracked by websites like advertising networks. For a sensitive browsing session you can temporarily enable private browsing which will help keep traces of that session hidden.
  2. Keep your software up-to-date: Ensure any software you download to your desktop or your mobile device – including apps and add-ons – stays updated.
  3. Secure your passwords: Create a unique password for each of your accounts by using a variety of upper and lowercase letters, numbers and punctuation marks. The new Firefox Sync makes it even easier to access your bookmarks, history, Awesome Bar intelligence, passwords, form-fill data and open tabs from Firefox running on other computers and mobile phones.
  4. Look for the S: Never purchase anything from a site that doesn’t have SSL/TLS encryption. You’ll know because the site’s address will start with https:// instead of http://. Additionally, never provide your credit card information via email.
  5. Don’t sacrifice security for mobility: Don’t just stop at your home computer. Extend your security to browsing from your mobile phone by making sure you’re always connected to a secure wireless network or your mobile provider’s 3G network before you enter any personal information or passwords or do any online shopping.

The Web is awesome. While we easily get lost in all the amazing stuff we can do online, this June the Anti-Phishing Working Group and National Cyber Security Alliance are encouraging people to Stop, Think, Connect to stay safe online.

Introducing Mozilla Winter of Security 2014

Curtis Koenig

20

At Mozilla, we have a loosely formed group called Security Automation, where people who build security tools can meet, exchange ideas, and show their work. We build projects around applications and operations security. Some of the things we’ve worked on include ZAP, Zest, Plug’n’Hack, Minion, MIG, Mozdef, ScanJS or Cipherscan. And, as you would expect from Mozilla, our work is public for all to see, use, and contribute to.

In the past, students requested to work on some of these projects. One trend we’ve seen is that many students are looking for real world projects to sink their teeth into. Something worth their attention, and something people will actually use.

In response we decided to create the Mozilla Winter of Security, or MWoS. MWoS is composed of 11 projects from the Security Automation effort, that directly map the needs at Mozilla. They are designed to solve real world problems in an innovative, and open way. We also made them autonomous, such that students don’t need to learn the inner-working of Mozilla in order to work on these projects.

Winter of Security, so called because we want students to get involved 800px-Redpandas4430roughly between September and April. Each project has an advisor from Mozilla who will be dedicating a few hours every week to the students. We also ask that a professor oversees the team from a university point of view, and ensures the projects align with their curriculum.
Anyone can apply, under the condition that the university will give class credits and a grade for the work done in MWoS.

MWoS is a win for all. Students get a chance to work on real-world security projects, under the guidance of an experienced security engineer. Professors get to implement cutting-edge security projects into their programs. Mozilla and the community get better security tools, which that we would not have the resources to build or improve ourselves.

If you are a professor, tell your students about the Mozilla Winter of Security today. If you are a student, start assembling your team, and fill up the application form before July 15th, 2014. We limited this round to 11 projects, with one team per project, and will be selecting the best applications in August.

If you have questions, and want to discuss MWoS, you can reach us on IRC in the #security channel, or via the discussion page on the wiki. If you want details about a specific project, feel free to contact the project advisor directly on IRC.

MWoS is part of the wider Mozilla Security Mentorship program.

Red Panda photograph from WikiMedia Commons under theCreative CommonsAttribution-Share Alike 3.0 Unported license.

Checking Compliance Status with Updated CA Certificate Policy

kwilson

In early 2013 Mozilla released version 2.1 of Mozilla’s CA Certificate Policy, which added 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. Then, in July, we updated Mozilla’s CA Certificate Enforcement Policy to make it clear that Mozilla will not tolerate misuse of publicly trusted certificates. CAs were given a grace period of just over one year to comply with the changes introduced in version 2.1 of the policy. So, today we sent an email to all Certificate Authorities (CAs) in Mozilla’s CA program to check on their progress.

The communication includes the following 5 action items for CAs.

  1. Ensure that Mozilla’s spreadsheet of included root certificates has the correct link to your most recent audit statement, and that the date of the audit statement is correct.
  2. Send Mozilla the link to your most recent Baseline Requirements audit statement.
  3. Test Mozilla’s new Certificate Verification library with your CA hierarchies and inform your customers of the upcoming changes as needed.
  4. Check your certificate issuance to confirm that no new certificates will be issued with the problems listed here.
  5. Send Mozilla information about your publicly disclosed subordinate CA certificates that chain up to certificates in Mozilla’s CA program, as per Items #8, 9, and 10 of Mozilla’s CA Certificate Inclusion Policy.

The full CA Communication is available here, and responses will be tabulated here.

We closed the communication by re-iterating 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 Engineering Team

Hack in the Box HackWeekDay 2014

Paul Theriault

The Mozilla security team is proud to be once again sponsoring the Hack-in-the-Box HackWeekDay competition, this time at the Haxpo conference in Amsterdam, 28-30 May 2014. Come learn about Firefox OS, make apps to compete for great prizes and help shape the future of the mobile web.

This HackWeekDay event is the biggest yet, and will actually be run over the course of three separate days. There will daily prizes, and you can compete in as many days as you want:

  • Day 1: Firefox OS Homescreen & WebRTC applications
  • Day 2: Facebook Social/Parse APIs applications
  • Day 3: Combined app hacking competition – build on your apps from previous days, or come up with a new app, and compete for the grand prize of most 1337 app.

You can attend just one day, or compete in all three. For details of the prizes on offer and how to get involved, see the HackWeekDay page on the HITB website.

Firefox OS Homescreen & WebRTC applications

For the the first day (28th May), the competition will focus on creating Firefox OS App which incorporates one of the following themes:

  • Replaceable Homescreen: prototype new homescreen ideas for Firefox OS, and implement this using the new replaceable homescreen feature
  • WebRTC: prototype an app which uses WebRTC, taking advantage of WebRTC to access camera, microphone and/or peer-to-peer networking.

A group of Mozillians will be there to help developers test their entries on Firefox OS devices and award prizes (including the new Firefox OS Flame developer phones!)

Register Now!

How can people get prepared?

Interested developers who want to get started should get familiar with how to develop Apps for Firefox OS and learn about WebRTC:

If you want to develop on Firefox OS itself, see the Hacking on Gaia page on MDN.

What are we looking for in the entries?

  • Prototypes which effectively demonstrate a new or interesting feature
  • Innovative use of Web APIs
  • High quality execution (especially on the constraints of mobile)
  • Benefits for the security and privacy of Firefox OS users

What about others who can’t attend the conference ?

  • Make apps for the Mozilla marketplace
  • Volunteer to help Mozilla security team on Firefox OS (or anything else) (come find us on irc.mozilla.org#security or email security@mozilla.org)

Will the community be there?

Yes! Mozilla Nederland is planning a presence at the event.

 

$10,000 Security Bug Bounty for Certificate Verification

Daniel Veditz

2

Firefox developer builds (“Nightly“) are now using a new certificate verification library we’ve been working on for some time, and this code is on track to be released as part of Firefox 31 in July. As we’ve all been painfully reminded recently (Heartbleed, #gotofail) correct code in TLS libraries is crucial in today’s Internet and we want to make sure this code is rock solid before it ships to millions of Firefox users. To that end we’re excited to launch a special Security Bug Bounty program that will pay $10,000 for critical security flaws found and reported in this new code before the end of June.

To qualify for the special bounty the bug and reporter must first meet the guidelines of our normal security bug bounty program (first to file wins in case of duplicates, employees are not eligible, and so on). In addition, to qualify for the special bounty amount the vulnerability must:

  • be in, or caused by, code in security/pkix or security/certverifier as used in Firefox
  • be triggered through normal web browsing (for example “visit the attacker’s HTTPS site”)
  • be reported in enough detail, including testcases, certificates, or even a running proof of concept server, that we can reproduce the problem
  • be reported to us by 11:59pm June 30, 2014 (Pacific Daylight Time)

We are primarily interested in bugs that allow the construction of certificate chains that are accepted as valid when they should be rejected, and bugs in the new code that lead to exploitable memory corruption. Compatibility issues that cause Firefox to be unable to verify otherwise valid certificates will generally not be considered a security bug, but a bug that caused Firefox to accept forged signed OCSP responses would be.

Valid security bugs that don’t meet the specific parameters of this special program remain eligible for our usual $3000 Security Bug Bounty, of course.

To enter the program please file a security bug at https://bugzilla.mozilla.org/ and send the bug ID or link by mail to security@mozilla.org. If for some reason you cannot file a bug you can send all the details by email, but filing the bug yourself has a couple of advantages for you. First, you will automatically be involved in any discussions the developers have about your bug, and second, if there are multiple reports of the same vulnerability the earliest bug filed wins the bounty. If you wish to encrypt mail to us our key can be found at https://www.mozilla.org/security/#pgpkey.

Exciting Updates to Certificate Verification in Gecko

cviecco

9

Today we’re excited to announce a new certificate verification library for Mozilla Products – mozilla::pkix! While most users will not notice a difference, the new library is more robust and maintainable. The new code is more robust because certificate path building attempts all potential trust chains for a certificate before giving up (acknowledging the fact that the certificate space is a cyclic directed graph and not a forest). The new implementation is also more maintainable, with only 4,167 lines of C++ code compared to the previous 81,865 lines of code which had been auto-translated from Java to C. The new library benefits from C++ functionality such as memory cleanup tools (e.g., RAII).

To provide some more background, Gecko has historically used the certificate verification processing in NSS to ensure that the certificates presented during a TLS/SSL handshake is valid. NSS currently has two code paths for doing certificate verification: “classic” used by Gecko for Domain Validated (DV) certificate verification, and libPKIX used by Gecko for Extended Validation (EV) certificate verification. The NSS team has wanted to replace the “classic” verification with libPKIX for some time because libPKIX handles cross-signed certificates better and properly handles certificate policies required for Enhanced Validation (EV) certificates. However, libPKIX has proven to be very difficult to work with.

We also took the opportunity to enforce some requirements in Mozilla’s CA Certificate Policy and in the CA/Browser Forum’s Baseline Requirements (BRs). The changes are listed here. While we have performed extensive compatibility testing, it is possible that your website certificate will no longer validate with Firefox 31. This should not be a problem if you use a certificate issued by one of the CAs in Mozilla’s CA Program, because they should already be issuing certificates according to Mozilla’s CA Certificate Policy and the BRs. If you notice an issue due to any of these changes, please let us know.

We are looking for feedback with respect to compatibility and security. For compatibility, we ask all site operators and security testers to install Firefox 31 and use it to browse to your favorite sites. In addition, we ask for willing C++ programmers out there to review our code. This new mozilla::pkix library is located at security/pkix and security/certverifier. A more detailed description is here. If you find an issue, please help us make it better by filing a Bugzilla bug report.

We look forward to your feedback on this new certificate verification library.

Mozilla Security Engineering Team