Firefox and Chromium Security

Last edited: October 13, 2020

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, 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. This 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. One example is that there is no sandboxing at all for the GPU process.
• Another example is that the seccomp filter is weaker; for example, 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. It is somewhat similar to NT's Win32k. Android implemented ioctl filtering in its application sandbox for this exact reason. Chromium allows only a few ioctls which reduces attack surface a considerable amount. These issues are only a few examples and there are a lot more issues with the sandbox.
• 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.

Firefox's Exploit Mitigations

Exploit mitigations are self-explanatory. They mitigate certain types of exploits. 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 good 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 mitigations like NX making older 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 much harder. In this study, it shows that Chromium's JIT engine has far better mitigations than Firefox's.
• A very basic exploit technique is simply to find a way to execute the attackers 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 though but this article doesn't need to be a full novel. 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 so this isn't anything substantial and Chromium is working on switching to memory-safe languages too.

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