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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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 |
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.
On Linux, Android and ChromeOS, Chromium enables Clang's fine-grained, forward-edge
CFI. On Windows, it enables the
weaker, coarse-grained, forward-edge Control Flow Guard (CFG), although Chromium has
been investigating deploying Clang CFI on Windows.
Mozilla has been planning to implement forward-edge CFI for a while but has yet to make significant
progress. Firefox only enables CFG on Windows; this is not as effective as Clang's CFI because it is
coarse-grained rather than fine-grained, and this does not apply to other platforms, which are currently devoid of any protection.
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.
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 |
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:
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.
Furthermore, Firefox lacks a hardened memory allocator. Firefox currently uses
mozjemalloc, which is a fork of jemalloc. Jemalloc is a performance-oriented
memory allocator — it does not have a focus on security, which makes it
very prone to exploitation. Mozjemalloc does add on a few security features to jemalloc which are useful, but they are not enough to
fix the issues present in the overall architecture of the allocator. Chromium instead uses
PartitionAlloc (throughout the entire codebase due to PartitionAlloc-Everywhere), which is
substantially more hardened than mozjemalloc is.
In comparison to mozjemalloc, a few examples of the security features present in PartitionAlloc which do not exist in mozjemalloc
are detailed below.
Memory partitioning is an exploit mitigation in which the memory allocator
segregates different objects into their own separate, isolated heap, based on their type and size so that, for example, a heap overflow would not be able corrupt an object from another heap.
Chromium's PartitionAlloc was explicitly designed with this mitigation in mind (hence the name); strong memory partitioning with no reused memory between partitions
is one of PartitionAlloc's core goals.
Firefox's mozjemalloc also eventually implemented some support for partitioning. However, memory is reused across partitions, thus severely weakening this feature and allowing it to be bypassed. Therefore, mozjemalloc's
implementation of memory partitioning does not guarantee strong isolation to the same extent as PartitionAlloc. In fact, a real-world exploit used by the FBI to unmask users of the Tor Browser
was possible due to the lack of memory partitioning.
Traditional heap exploitation techniques often rely on corrupting the memory allocator
metadata. PartitionAlloc stores most metadata out-of-line
in a dedicated region (with the exception of freelist pointers, although they have other protections) rather than having it adjacent to the allocations, thereby significantly
increasing the difficulty of performing such techniques.
Unlike PartitionAlloc, mozjemalloc currently places heap metadata in-line with allocations. As such, the aforementioned
techniques are still possible and allocator metadata is easier to corrupt.
Moreover, PartitionAlloc also makes use of guard pages — inaccessible areas of memory that cause an error upon any attempts at accessing it — to surround the metadata, as well as various
other allocations to protect them from linear overflows; this is another security feature that mozjemalloc lacks.
PartitionAlloc has a naive check for
double frees, but it isn't difficult to bypass, so it's not a major feature.
More importantly, PartitionAlloc is working on many promising upcoming security features, such as their
MiraclePtr and *Scan projects to effectively mitigate most use-after-free exploits.
One of the most common classes of memory corruption vulnerabilities is uninitialised memory. Clang has an option to
automatically initialise stack variables with either zero or a specific pattern, thus mitigating this class of vulnerabilities for the stack. Chromium enables this by default on all platforms except
Android, whereas Firefox only enables it in debugging builds for uncovering bugs and is not used in production to mitigate
exploits.
As for the heap, both PartitionAlloc and mozjemalloc zero-fill allocations, so they are equivalent in that regard.
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.
Many security experts also share these views about Firefox, and a few examples are listed below: