Firefox Security Newsletter/FSN-2020-Q4

From MozillaWiki
Jump to: navigation, search

Firefox Security & Privacy Newsletter 2020 Q4


Hello fellow Mozillians,


The various security and privacy teams at Mozilla work in different parts of the organization, and on different projects, but all with one goal in common: to improve every aspect of Firefox’s security and privacy, and to keep our users safe. Since not all of these projects are directly visible to everyone, we’ve pulled together the highlights from Q4 2020. We also want to use this newsletter to acknowledge contributions of folks whose day job is not specifically privacy/security-related but who have improved security and privacy-relevant aspects in their areas.


To ease consumption of the many security and privacy-related improvements listed within this newsletter, we have grouped them into the following categories:

  • Product Security & Privacy, showcasing new Security & Privacy Products, Features and Services.
  • Core Security, outlining Security and Hardening efforts within the Firefox Platform.
  • Cryptography, showcasing improvements to connection security.
  • Fuzzing, providing updates for automated security testing and analysis.
  • Web Security, highlighting the support of new web application security features.
  • Policy & Bug Bounty, providing updates on security policy development.


Note: Some of the bugs linked below might not be accessible to the general public and are still restricted to specific work groups. We derestrict fixed security bugs after a grace-period, until the majority of our user population have received their updates.

Product Security & Privacy

HTTPS-Only Mode:

The number of websites that support encrypted and secure HTTPS connections has been increasing rapidly in recent years. Despite major gains in the proportion of websites supporting https, the web contains millions of legacy http links that point to insecure versions of websites where browsers traditionally would connect using the outdated and insecure http protocol. To compensate, Firefox 83 provides an HTTPS-Only Mode. This new opt-in, security-enhancing feature first tries to establish a secure connection to a website using https and permits the user to fallback to http manually if a secure connection cannot be established. We believe that HTTPS-Only paves the way to achieving a fully secure web and this initial version is the starting point for all browser vendors to re-evaluate their default connection model.


Redirect Tracking Protection:

The Redirect tracking protection was originally introduced into Firefox 79. In recent efforts we made the data purging mechanism more intelligent to ensure that users are not logged out of sites that they are visiting.


Core Security

Visibility and Transparency:

Providing architectural insights into the security design of a system is crucial for truly working in the open and ultimately allows contributors, hackers, and bug bounty hunters to verify and challenge our design decisions. To increase transparency on Mozilla’s Security and Privacy efforts we have invited three authors to publish guest blog posts on the Attack & Defense Blog. These posts not only emphasize our relationships with the community but also hopefully encourage more security and privacy-minded people to contribute. In particular, we have published:


In addition to the above articles featured on our Blog, we have also published insights into Firefox-related bugs, news about browser security in general, and further bite-sized security announcements on our Attack & Defense Twitter account.


Ending support for Flash and AppCache:

Firefox 84 is the last version to support Flash - this change eliminates long-standing security vulnerabilities within browsers for good, and there is no setting to re-enable Flash as announced in End of support for Adobe Flash. Further, Firefox 84 has disabled the application cache feature, which happened in collaboration with other major browsers.


Hardening Efforts:

We have enabled the Code Integrity Guard in the RDD process before process creation, which is a mitigation that prevents loading unknown and potentially malicious code into the process’ memory. Further, we have enabled Address Sanitizer and Control Flow Guard for Rust code in our linux64-asan builds - both features allow detection of memory corruption vulnerabilities and hence offer improved security guarantees for Firefox.


New JIT Backend “Warpbuilder”:

Firefox 83 is the first release that ships with Warpbuilder, a new backend for our JavaScript Just-In-Time compilation. While the main objective for adding Warpbuilder was to boost performance, this redesign also combats all sorts of JIT-type confusion bugs. Put differently, we believe that this simplification in type inferring reduces the number of JIT-related security bugs.

Cryptography

Preloading Intermediate CA Certificates:

In November we published a chart showing the reduction of unknown issuer errors since preloading of intermediate certificates was first introduced into Firefox. Preloading of intermediate certificates uses the Common CA Database (CCADB) which makes all of the relevant intermediate CA certificates available via CCADB[1]reporting mechanisms. Given this information, we periodically synthesize a list of these intermediate CA certificates and place them into Remote Settings. Currently the list contains over two thousand entries.


CRLite:

In December we concluded a 4-part explanation about CRLite (part 1 compression; part 2 design; part 3 performance; part 4 infrastructure). In the future, CRLite will provide Firefox users with the confidence that the revocations in the Web PKI are enforced by the browser without privacy compromise.


Root Store Data:

We are now publishing Mozilla's root store in a way that is easy to consume by others, and added data-usage terms. Mozilla’s root store data can be found via new links in https://wiki.mozilla.org/CA/Included_Certificates which are made available via Common CA Database (CCADB) reports.


Root Store Updates:

Added root certificates for NAVER and SecureTrust CAs. Removed ten GeoTrust, thawte, and VeriSign root certificates (Bugzilla #1670769), as part of the continued efforts to distrust the old Symantec root certificates. Also removed the EE Certification Centre Root CA and Taiwan Government Root Certification Authority root certificates. Turned off the websites (TLS) trust bit for OISTE WISeKey Global Root GA CA root certificate.


QWACs (Qualified Website Authentication Certificates):

In October we published a blog post explaining our response to the European Commission on its survey and public consultation regarding the eIDAS regulation, advocating for an interpretation of eIDAS that is better for user security and retains innovation and interoperability of the global Internet.


CCADB:

Extended automated audit letter validation (ALV) to EV TLS audits for intermediate certificates, and added reporting to the CA home pages to resolve problems with EV-TLS-capable intermediate certificates not being listed in the scope of the appropriate audit statements.

Fuzzing

ThreadSanitizer:

We enabled more tests in our CI and started fuzzing TSan builds to find more data races. In the process, we also filed 39 more bugs, most of which have been fixed by now. These bugs again included several potential security issues, mostly but not limited to lifetime issues (use-after-free). Overall we can conclude that the project has turned up a large number of interesting bugs in 2020 and recommend deployment of ThreadSanitizer along with AddressSanitizer for any large multithreaded C/C++ application.


LibFuzzer targets:

We continued to develop fuzzing targets internally utilizing the JSRT part of the fuzzing interface, a bridge that allows development of libFuzzer targets for the JS engine only using JavaScript.


Bug Life-Cycle Management:

We expanded access to Bugmon, a tool for automatic analysis and bisection for Bugzilla test cases to the general public. We later published Bugmon and its capabilities in the MozHacks post, Analyzing Bugzilla Testcases with Bugmon.

Web Security

Supporting sandbox=’allow-downloads’:

The iframe sandbox attribute allows lock-down capabilities of embedded third-party content. Starting with Firefox 82 downloads initiated by sandboxed iframes without the attribute ‘allow-downloads’ will be blocked. This new security attribute allows web applications to protect their users from potentially malicious content in sandboxed iframes to initiate drive-by downloads which could jeopardize a user’s security.


Eliminating cross-origin access to window.name:

It’s well-known that certain XSS exploitation vectors exist when websites store and access payload information through window.name. Firefox now clears this value during cross-origin navigation to make it harder to carry out XSS attacks.


Advancing Mixed Content Blocking:

One of our main goals is to bring more https adoption to the web. En route we are constantly improving Firefox’s implementation of the Mixed Content Blocker. This time we started to hardcode localhost names to loopback addresses and further we stop treating "http://localhost/" (by name) as mixed content. Both these adjustments allow for improved usability but at the same time live up to our security standards.


Going Forward

Thanks to everyone involved in making Firefox and the Open Web more secure and privacy-respecting. Since we are already in Q1, please do not forget to add your items to the 2021 Q1 security privacy newsletter collection document so that they will show up in the next iteration of the Security Privacy newsletter.


In the name of everyone improving Security and Privacy within Firefox, Mozilla and the Open Web,

Christoph, Freddy, Tom