Hello fellow Mozillians,
Here comes our Q4 edition of the Firefox Security & Privacy Newsletter.
The shareable link for this newsletter is
(References are in footnotes at the bottom, due to dev-platform being a
text-only mailing list. You can always read on the wiki instead).
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
- Cryptography, showcasing improvements to connection security.
- Fuzzing, providing updates for automated security testing and
- Web Security, highlighting the support of new web application
- Policy & Bug Bounty, providing updates on security policy
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.
[We derestrict fixed security bugs after a grace-period]:
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
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.
[Firefox 83 provides an HTTPS-Only Mode]:
[Redirect tracking protection]:
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:
- Insights into a [Rollback Attack] from [Xiaoyin Liu]
- [Firefox for Android LAN-Based Intent Triggering] from Chris
- [Good First Steps to Find Security Bugs in Fenix] by Muneaki
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
Just-In-Time compilation][Warpbuilder]. 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
[Attack & Defense Blog]: https://blog.mozilla.org/attack-and-defense/
[Firefox for Android LAN-Based Intent Triggering]:
[Good First Steps to Find Security Bugs in Fenix]:
[Attack & Defense Twitter account]: https://twitter.com/attackndefense
[End of support for Adobe Flash.]:
[disabled the application cache feature]:
[Code Integrity Guard in the RDD process]:
[Address Sanitizer]: https://bugzilla.mozilla.org/show_bug.cgi?id=1563019
[Control Flow Guard]: https://bugzilla.mozilla.org/show_bug.cgi?id=1632866
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[ ][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
] 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
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
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.
[preloading of intermediate certificates]:
[Common CA Database (CCADB)]: https://www.ccadb.org/
[Bugzilla #1670769]: https://bugzilla.mozilla.org/show_bug.cgi?id=1670769
[old Symantec root certificates]:
[EE Certification Centre Root CA]:
[Taiwan Government Root Certification Authority]:
[OISTE WISeKey Global Root GA CA]:
[blog post explaining our response]:
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
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].
[JSRT part of the fuzzing interface]:
[Analyzing Bugzilla Testcases with Bugmon]:
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
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.
[Firefox 82 downloads initiated by sandboxed iframes without the
attribute ‘allow-downloads’ will be blocked]:
[Firefox now clears this value during cross-origin navigation]:
[hardcode localhost names to loopback addresses]:
[stop treating "http://localhost/
" (by name) as mixed content]:
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
[2021 Q1 security privacy newsletter collection document]: