Last edited: March 19th, 2022

Firefox is sometimes recommended as a supposedly more secure browser because of its parent company’s privacy practices. This article explains why this notion is not true and enumerates a number of security weaknesses in Firefox’s security model when compared to Chromium. In particular, it covers the less granular process model, weaker sandboxing and lack of modern exploit mitigations. It is important to decouple privacy from security — this article does not attempt to compare the privacy practices of each browser but rather their resistance to exploitation.

Section 1 explains the weaker process model and sandboxing architecture. Section 2 examines and compares a number of important exploit mitigations. Section 3 discusses some miscellaneous topics. Finally, section 4 provides links to what other security researchers have said about this topic.

Contents

1. Sandboxing 1.1 Site Isolation 1.2 Windows 1.3 Linux 1.3.1 Linux Sandbox Escapes 1.3.2 seccomp-bpf 1.4 Android 1.5 Missing Processes 2. Exploit Mitigations 2.1 Arbitrary Code Guard and Code Integrity Guard 2.2 Control Flow Integrity 2.2.1 Forward-edge CFI 2.2.2 Backward-edge CFI 2.3 Untrusted Fonts Blocking 2.4 JIT Hardening 2.5 Memory Allocator Hardening 2.5.1 Memory Partitioning 2.5.2 Out-of-line Metadata 2.5.3 Other 2.6 Automatic Variable Initialisation 3. Miscellaneous 4. Other Security Researchers’ Views on Firefox

1. Sandboxing

Sandboxing is a technique used to isolate certain programs to prevent a vulnerability in them from compromising the rest of the system by restricting access to unnecessary resources. All common browsers nowadays include a sandbox and utilise a multi-process architecture. The browser splits itself up into different processes (e.g. the content process, GPU process, RDD process, etc.) and sandboxes them individually, strictly adhering to the principle of least privilege. It is very important that a browser uses a sandbox, as it processes untrusted input by design, poses enormous attack surface and is one of the most used applications on the system. Without a sandbox, any exploit in the browser can be used to take over the rest of the system. Whereas with a sandbox, the attacker would need to chain their exploit with an additional sandbox escape vulnerability.

However, sandboxes are not black and white. Just having a sandbox doesn’t do much if it’s full of holes. Firefox’s sandbox is quite weak for the reasons documented below. Note that this is a non-exhaustive list, and the issues below are only a few examples of such weaknesses.

1.1 Site Isolation

Site isolation is a security feature which was introduced in Chromium in 2018. This involved an overhaul in Chromium’s multi-process architecture — rather than all websites running within the same process, this feature now separated each website into its own sandboxed renderer process. This ensures that a renderer exploit from one website still cannot access the data from another. In addition, site isolation is necessary for complete protection against side-channel attacks like Spectre. Operating system mitigations against such attacks only guarantee isolation at the process boundary; therefore, separating websites into different processes is the only way to fully make use of them. Furthermore, current browser mitigations, such as reducing JavaScript timer accuracy, are insufficient and do not address the root issue. As such, the only proper mitigation is through site isolation.

Firefox fully rolled out their Fission project in Firefox 95. However, Fission in its current state is not as mature as Chromium’s site isolation, and it will take many more years for it to reach that point. Fission still suffers from all the security issues of the baseline content process sandbox, as documented below, and it is not a panacea for all sandboxing issues. However, more specific to Fission itself, there are numerous cross-site leaks, allowing a compromised content process to access the data of another and bypass site isolation.

1.2 Windows

Excluding the issue of site isolation, only the Firefox sandbox on Windows is even comparable to the Chromium sandbox; however, it still lacks win32k lockdown. Win32k is a set of dangerous system calls in the NT kernel that expose a lot of attack surface and has historically been the result of numerous vulnerabilities, making it a frequent target for sandbox escapes. Microsoft aimed to lessen this risk by introducing a feature that allows a process to block access to these syscalls, therefore massively reducing attack surface. Chromium implemented this feature in 2016 to strengthen the sandbox, but Firefox has yet to follow suit — Firefox currently only enables this in the socket process (which isn’t enabled yet).

1.3 Linux

1.3.1 Sandbox Escapes

Firefox’s sandboxing on other platforms, such as Linux, is significantly worse. The restrictions are generally quite permissive, and it is even susceptible to various trivial sandbox escape vulnerabilities that span back years, as well as exposing sizable attack surface from within the sandbox.

• One example of such sandbox escape flaws is X11 — X11 doesn’t implement any GUI isolation, which makes it very easy to escape sandboxes with it. Chromium resolves this issue by only permitting access to X11 from within the GPU process so that the renderer process (the process in which websites are loaded) cannot access it, whereas on Firefox, it is exposed directly to the content process.
• PulseAudio is a common sound server on Linux. However, it was not written with isolation in mind, making it possible to escape sandboxes with it. Like X11, Firefox exposes this directly to the content process, permitting another trivial sandbox escape, while Chromium only exposes it to a dedicated audio service.

1.3.2 seccomp-bpf

seccomp-bpf is a sandboxing technology on Linux that allows one to restrict the syscalls accessible by a process, which can greatly reduce kernel attack surface and is a core part of most Linux sandboxes. However, Firefox’s seccomp filter is substantially less restrictive than the one imposed by Chromium’s sandbox and does not restrict anywhere near the same amount of syscalls and their arguments. One example of this is that there is very little filtering of ioctl calls — only TTY-related ioctls are blocked in the content process. This is problematic because ioctl is a particularly powerful syscall that presents a massive kernel attack surface, as it comprises of hundreds of different syscalls, somewhat similar to NT’s Win32k. Unlike Firefox, Chromium permits only the few ioctls that are necessary in its sandbox, which reduces kernel attack surface by a considerable amount. In a similar fashion, Android implemented ioctl filtering in its application sandbox for the same reasons, alongside various other projects with a focus on sandboxing.

1.4 Android

On Android, Firefox has implemented a multi-process architecture since 2021; however, this is still severely limited, and no sandboxing is enabled. Whereas Chromium uses the isolatedProcess feature, along with a more restrictive seccomp-bpf filter.

1.5 Missing Processes

In general, Chromium’s multi-process architecture is significantly more mature and granular than that of Firefox, allowing it to impose tighter restrictions upon each part of the browser. Examples of processes that are missing from Firefox are listed below. On Firefox, such functionality will be merged into another process, such as the parent or content process, making it considerably harder to enforce strong restrictions.

• On Linux, Firefox has no separate GPU process, meaning it cannot be independently sandboxed. This process exists on Windows, although the sandboxing for it is still not enabled.
• Firefox does not yet have a separate socket process for network operations — this process only exists in Nightly and doesn’t include anything other than WebRTC code, unlike Chromium’s dedicated network service.
• Firefox also does not have an audio process, whereas Chromium has a dedicated audio service. The lack of such a process in Firefox means that audio functionality is merged into the content process, which is the cause of the PulseAudio sandbox escape vector on Linux systems.
• Further examples include text-to-speech, printing backend and compositor, speech recognition, proxy resolver and more.

Later in this article, tables are presented which directly compare some of the mitigations used in Chromium processes to their Firefox equivalents. However, they do not list every single process because they would become huge and Firefox would only have a small fraction of processes to be compared with. Instead, only a subset of particularly important processes are included.

2. Exploit Mitigations

Exploit mitigations eliminate entire classes of common vulnerabilities / exploit techniques to prevent or severely hinder exploitation. Firefox lacks many important mitigations, while Chromium generally excels in this area.

As with the sandboxing, there are many more issues than the ones listed below, but this article does not attempt to be an exhaustive list. Readers can look through Mozilla’s own bug tracker for further examples.

2.1 Arbitrary Code Guard and Code Integrity Guard

A very common exploit technique is that during exploitation of a buffer overflow vulnerability, an attacker injects their own malicious code (known as shellcode) into a part of memory and causes the program to execute it by overwriting critical data, such as return addresses and function pointers, to hijack the control flow and point to the aforementioned shellcode, thereby gaining control over the program.

The industry eventually evolved to mitigate this style of attacks by marking writable areas of memory as non-executable and executable areas as non-writable, preventing an attacker from injecting and executing their shellcode. However, an attacker can bypass this by reusing bits of code already present within the program (known as gadgets) outside of the order in which they were originally intended to be used. An attacker can form a chain of such gadgets to achieve near-arbitrary code execution despite the aforementioned protections, utilising techniques such as Return-Oriented Programming (ROP) or Jump-Oriented Programming (JOP).

Attackers often inject their shellcode into writable memory pages and then use these code reuse techniques to transition memory pages to executable (using syscalls such as mprotect or VirtualAlloc), consequently allowing it to be executed. Windows 10 implemented a mitigation known as Arbitrary Code Guard (ACG), which mitigates this by ensuring that all executable memory pages are immutable and can never be made writable.

Another mitigation known as Code Integrity Guard (CIG) is similar to ACG, but it applies to the filesystem instead of memory, ensuring that an attacker cannot execute a malicious program or library on disk by guaranteeing that all binaries loaded into a process must be signed. Together, ACG and CIG enforce a strict W^X policy in both memory and the filesystem.

In 2017, Chromium implemented support for ACG and CIG as MITIGATION_DYNAMIC_CODE_DISABLE and MITIGATION_FORCE_MS_SIGNED_BINS, but Firefox has yet to implement comparable support for either ACG or CIG. Currently, Firefox only enables ACG and CIG in the socket process (which isn’t enabled yet) and CIG in the RDD process.

However, Chromium’s application of ACG is still currently limited due to the inherent incompatibility with JIT engines, which dynamically generate code (JIT is explained in further detail below). ACG is primarily enabled in relatively minor processes, such as the proxy resolver and icon reader processes; however, some notable ones, such as the audio process, also have it enabled. Additionally, if V8’s JITless mode is enabled, then Chromium also enables ACG in the renderer process; Firefox does not enable ACG in the renderer regardless of JIT.

ACG
	Chromium	Firefox
Renderer/Content	N*	N
GPU	N	N
RDD	N	N
Extensions	N	N
Network/Socket	N*	N/A
Audio	Y	N/A

* Chromium enables ACG in the renderer process when running in JITless mode. * Chromium enables ACG in the network process if the NetworkServiceSandbox feature is enabled.

CIG
	Chromium	Firefox
Renderer/Content	Y	N
GPU	Y	N
RDD	Y	Y
Extensions	Y	N
Network/Socket	N*	N/A
Audio	Y	N/A

* Chromium can optionally enable CIG in the network process if the NetworkServiceCodeIntegrity feature is enabled.

2.2 Control Flow Integrity

As briefly mentioned before, code reuse attacks can be used to achieve near-arbitrary code execution by chaining together snippets of code that already exist in the program. ACG and CIG only mitigate one potential attack vector — creating a ROP/JOP chain to transition mappings to executable. However, an attacker can still use a pure ROP/JOP chain, relying wholly on the pre-existing gadgets without needing to introduce their own code. This can be mitigated with Control Flow Integrity (CFI), which severely restricts the gadgets an attacker is able to make use of, thus disrupting their chain.

CFI usually has 2 parts: forward-edge protection (covering JOP, COP, etc.) and backward-edge protection (covering ROP). CFI implementations can vary significantly. Some CFI implementations only cover either forward-edges or backward-edges. Some are coarse-grained (the attacker has more freeway to execute a larger amount of gadgets) rather than fine-grained. Some are probabilistic (they rely on a secret being held and the security properties are not guaranteed) rather than deterministic.

2.2.1 Forward-edge CFI

2.2.2 Backward-edge CFI

As for backward-edge protection, in 2021, Chrome implemented shadow stacks using Intel’s Control-flow Enforcement Technology (CET). Shadow stacks protect a program’s return address by replicating it in a different, hidden stack. The return addresses in the main stack and the shadow stack are then compared in the function epilogue to see if either differ. If so, this would indicate an attack and the program will abort, therefore mitigating ROP attacks. Chromium automatically enables this for all processes with a flag to opt out of it on a case-by-case basis. The only notable process that does opt out of CET is the renderer process. However, CET is enabled in the renderer when V8 is running in JITless mode, similar to ACG, as mentioned above.

Stable releases of Firefox currently lack any backward-edge protection. CET support has only been implemented in Firefox Nightly, but this still has incomplete coverage, and there is no protection for the renderer/content process regardless of the JIT engine’s status.

2.3 Untrusted Fonts Blocking

Untrusted fonts have historically been a common source of vulnerabilities within Windows. As such, Windows includes a mitigation to block untrusted fonts from specific processes to reduce attack surface. Chromium added support for this in 2016 in the form of MITIGATION_NONSYSTEM_FONT_DISABLE and enabled it for most child processes; however, Firefox has yet to enable this in any.

Untrusted Font Blocking
	Chromium	Firefox
Renderer/Content	Y	N
GPU	Y	N
RDD	Y	N
Extensions	Y	N
Network/Socket	N	N/A
Audio	Y	N/A

2.4 JIT Hardening

All mainstream browsers include a JIT compiler to improve performance. This involves dynamically compiling and executing JavaScript as native code; however, there is an inherent security hole in JIT, and that is the possibility of an attacker injecting arbitrary code as a result of JIT being an innate W^X violation, as discussed above. In an attempt to lessen the security risks posed by this feature without sacrificing the performance gains, browsers have adopted JIT hardening techniques to make exploiting the JIT compiler more difficult. In a study on attacking JIT compilers published by Chris Rohlf, the hardening techniques implemented in various JIT engines were analysed and compared. This study demonstrated that the JIT engine used in Chromium (V8) applies substantially better protections than the engine used in Firefox (JaegerMonkey). In particular, the mitigations which Chromium implemented that Firefox did not use include:

• Guard pages.
• Page randomization.
• Constant blinding.
• Allocation restrictions.
• NOP insertions.
• Random code base offset.

Since the publication of the paper, Firefox has made limited progress on adopting these techniques. Examples of lacking mitigations include constant blinding and NOP insertion. On the other hand, JIT hardening mitigations are not particularly strong and can often be bypassed, so these may not be as consequential as other security features.

Firefox did attempt to harden the JIT engine by adding a so-called “W^X JIT”, but this fails to hinder actual exploits, as it is vulnerable to a race window in which an attacker can write their shellcode to the memory mapping when it’s writable and wait for the engine to transition it to executable. Additionally, due to the lack of CFI in Firefox, there are also many gadgets available for an attacker to force transition the mapping to executable, such as ExecutableAllocator::makeExecutable or mprotect / VirtualAlloc in the C library. Furthermore, V8 has also adopted a similar, equally futile mitigation, so even if this were useful, it’s not an advantage over Chromium.

Something similar to Safari’s “Bulletproof JIT” would have been a better approach, utilising two separate mappings — one writable and one executable, with the writable mapping being placed at a secret location in memory, concealed via execute-only memory. Similarly, secure dynamic code generation (SDCG) would also be a better approach — SDCG works by dynamically generating code inside a separate, trusted process. This means that it’s not easily exploitable from within an untrusted renderer because the code is always read-only under all circumstances.

As PaX Team noted in 2015:

> but for this to be safe, the RW mapping should be in a separate process.

note that this is a weakness in the current mprotect based method as well as there’s still a nice race window for overwriting the JIT generated code. the only safe way i know of for JIT codegen is to basically fall back to what amounts to AOT codegen, i.e., a separate process (this would make it compatible with MPROTECT in PaX). there’s prior art for the V8 engine btw, check out the SDCG work presented at NDSS’15: http://wenke.gtisc.gatech.edu/papers/sdcg.pdf and https://github.com/ChengyuSong/v8-sdcg . [...] second, since there’s no control-flow integrity employed by Firefox (and it can’t have one until certain bad code constructs get rewritten) those ‘few code paths’ you mention are abusable by redirecting control flow there (ExecutableAllocator::makeExecutable is an obvious ROP target if one’s lazy to find mprotect itself in libc).

as for the size of the race window, there’re two problems with it: first, there’re many such windows as there’re a lot of users of AutoWritableJitCode (including embeddings) that execute lots of code during those windows (have you actually measured how long those windows are?). second, the window can effectively be extended to arbitrary lengths by first overwriting ExecutableAllocator::nonWritableJitCode to false.

in summary, this is a half-baked security measure that is DOA.

2.5 Memory Allocator Hardening

2.5.1 Memory Partitioning

2.5.2 Out-of-line Metadata

2.5.3 Other

2.6 Automatic Variable Initialisation

3. Miscellaneous

Firefox does have some parts written in Rust, a memory safe language, but the majority of the browser is still written in memory unsafe languages, and the parts that are memory safe do not include important attack surfaces, so this isn’t anything substantial, and Chromium is working on switching to memory safe languages too.

Additionally, writing parts in a memory safe language does not necessarily improve security and may even degrade security by allowing for bypasses of exploit mitigations. Some security features are geared towards a particular language, and in an environment where different languages are mixed, those features may be bypassed by abusing the other language. For example, when mixing C and Rust code in the same binary with CFI enabled, the integrity of the control flow will be guaranteed in the C code, but the Rust code will remain unchanged because buffer overflows are impossible in Rust anyway. However, this allows an attacker to bypass CFI by exploiting a buffer overflow in the C code and then abusing the lack of protection in the Rust code to hijack the control flow. Mixed binaries can be secure but only if those security features are applied for all languages. Currently, compilers generally don’t support this, excluding Windows’ Control Flow Guard support in Clang.

Firefox also uses RLBox, but this is currently only used to sandbox five libraries, which again, is not anything substantial and is not a replacement for a fine-grained sandboxing architecture covering the browser as a whole.

4. Other Security Researchers’ Views on Firefox

Many security experts also share these views about Firefox, and a few examples are listed below:

• thegrugq, information security researcher: Tor and its Discontents
• Kenn White, security researcher: https://twitter.com/kennwhite/status/804142071133126656
• PaXTeam, developer of PaX: https://archive.fo/9aBLk
• Daniel Micay, lead developer of GrapheneOS: https://grapheneos.org/usage#web-browsing
• Matthew Garrett, Linux developer: https://news.ycombinator.com/item?id=13800323
• Dan Guido, CEO of Trail of Bits: https://news.ycombinator.com/item?id=13623735
• Theo de Raadt, lead developer of OpenBsd: https://marc.info/?l=openbsd-misc&m=152872551609819&w=2
• Thomas Ptacek, co-founder of Latacora and Matasano Security: https://twitter.com/tqbf/status/930807512609296384, https://twitter.com/tqbf/status/930860544927649792, https://twitter.com/tqbf/status/830511154950766595
• qwertyoruiopz, iOS exploit developer: https://twitter.com/qwertyoruiopz/status/805887567493271556, https://twitter.com/qwertyoruiopz/status/730704655748075520
• John Wu, Android security engineer: https://twitter.com/topjohnwu/status/1105739918444253184, https://twitter.com/topjohnwu/status/1455606288419733505
• Chris Rohlf, security engineer: https://twitter.com/chrisrohlf/status/1455549993536966671
• Matthew Green, cryptographer at Johns Hopkins University: https://twitter.com/matthew_d_green/status/830488564672626690
• Bruno Keith, security researcher at Dataflow Security: https://twitter.com/bkth_/status/1265971734777380865
• Niklas Baumstark, security researcher at Dataflow Security: https://twitter.com/_niklasb/status/1131129708073107456
• The Tor Project investigating ways to harden the Tor Browser; in particular, they conclude that Firefox is too poorly written for them to apply PaX’s Reuse Attack Protector (in comparison, RAP can be applied to Chromium with relatively little effort): https://gitlab.torproject.org/tpo/applications/tor-browser/-/wikis/Hardening
• Alex Gaynor, former Firefox security engineer and sandboxing lead: https://news.ycombinator.com/item?id=22342352 Go back