Firefox and Chromium Security

Last edited: March 20, 2021

Chromium is far more secure than Firefox. Firefox's sandboxing and exploit mitigations are much poorer than Chromium's. This article is not blindly hating on Firefox but is a factual analysis of its weaknesses.

Firefox's Sandbox

Sandboxing is a technique used to isolate certain programs to prevent a vulnerability in them from compromising the rest of the system. All common browsers nowadays include a sandbox. The browser splits itself up into different processes (e.g. the content process, GPU process, etc.) and sandboxes them individually. It is very important that a browser uses a sandbox. Otherwise, any exploit in the browser can be used to take over the rest of the system. With a sandbox, they 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 following reasons:

• Firefox's sandboxing lacks any site isolation. Site isolation runs every website inside its own sandbox so that malware in one website cannot access the data from another. Mozilla is working on this with Project Fission but it is still a WIP. The sandbox is currently only focused on isolating the browser as a whole from the rest of the OS and even that is still not great.
• Excluding the issue of site isolation, only the Firefox sandbox on Windows is similar to Chromium's but even then, it lacks win32k lockdown. Win32k is a set of dangerous system calls in the NT kernel that expose a lot of attack surface and has been the result of many vulnerabilities before. Microsoft aimed to lessen this risk by introducing a feature that allows a program to block access to these syscalls, therefore massively reducing attack surface. Chromium implemented this in 2016 to strengthen the sandbox but Firefox has yet to follow suit.
• The sandboxing on other platforms is much worse and the Linux sandbox even has unfixed critical sandbox escape issues such as through the X11 server that go back as far as 5 years. The problem with X11 is that it doesn't implement any GUI isolation which makes it very easy to escape sandboxes. Chromium resolves this issue by only exposing X11 to the GPU process so the renderer process (the process in which websites are loaded) cannot access them.
• The issues with the Linux sandbox also go far beyond X11. Another example is that the seccomp filter is weaker; an example of this is that there is very little ioctl filtering and only TTY-related ioctls are blocked. Ioctl is a massive kernel attack surface that comprises of hundreds of different syscalls and is somewhat similar to NT's Win32k. Android implemented ioctl filtering in its application sandbox for this exact reason. Chromium permits only a few ioctls in its sandbox which reduces attack surface by a considerable amount.
• On Linux, there is also no separate GPU process, meaning it cannot be sandboxed. This process exists on Windows however, the sandboxing for it is still not enabled.
• On Android, Firefox does not have a sandbox at all beyond the OS app sandbox unlike Chromium which uses the isolatedProcess feature along with a more strict seccomp-bpf filter.

This is a non-exhaustive list — the above issues are only a few examples.

Firefox's 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.

• Firefox lacks a hardened memory allocator. Firefox currently uses mozjemalloc which is a fork of jemalloc. Jemalloc is a performance-oriented memory allocator — it doesn't focus on security which makes it very friendly to exploitation. Mozjemalloc does add on a few security features to jemalloc which is useful but it is not enough to fix the issues present in the overall architecture of the allocator. Chromium instead uses PartitionAlloc which is much more hardened than mozjemalloc.
• Control-Flow Integrity (CFI) is an exploit mitigation that aims to prevent code reuse attacks like ROP or JOP. A large portion of vulnerabilities are exploited using these techniques due to more widely adopted mitigations such as NX making older exploit techniques obsolete. Mozilla has been planning to implement CFI for a while but has yet to make much progress. On Linux and Android, Chromium uses Clang's forward-edge CFI and on Windows, they use Control Flow Guard.
• All common browsers include a JIT compiler to improve performance. There is an inherent security hole in JIT however and that is the requirement of memory that is both writable and executable (a W^X violation). Due to not wanting massive security issues while also wanting better performance, browsers have adopted JIT hardening techniques in an attempt to make exploiting JIT security issues significantly more difficult. In this study, it shows that Chromium's (V8) JIT engine has far better mitigations than Firefox's.
• A very basic exploit technique is simply to find a way to execute the attacker's own malicious code, either by loading a malicious library on disk or by dynamically modifying executable code in memory. Arbitrary Code Guard (ACG) and Code Integrity Guard (CIG) mitigate both of these issues. Chromium enables these by default, but Firefox lacks both ACG and CIG. Technically, this is only a issue on Windows but that's only because other operating systems lack these mitigations in the first place.
• There are many more issues than these but this is not an exhaustive list. You can look through Mozilla's own bug tracker for more examples.

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 only used to sandbox a single library, Graphite and again, is not anything substantial.

Other Security Researcher Views on Firefox

Many security experts also share these views about Firefox.

Go back