Firefox and Chromium
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
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
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 |
| 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 |
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
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.
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.
> 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
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.
2.5.1 Memory Partitioning
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.
2.5.2 Out-of-line Metadata
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.
2.5.3 Other
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.
2.6 Automatic Variable Initialisation
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.
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:
Debian User Forums
Suddenly a proces «RDD Proces» popped up in top. Never saw this one before.
Where i indeed ran firefox and youtube video the proces was eating 50% cpu time — realize that on background i run prime number software crunching at all cores 24/24.
Very obviously this RDD proces getting used to hack me.
cd /
px — ax | grep RDD
Then i couldn’t find RDD proces.
Also as root it wasn’t possible.
When as root i noticed the proces in top i killed the processnumber.
Now suddenly it shows up AFTER i killed it.
root@thegathering:/# ps -ax | grep RDD
10284 ? Z 57:19 [RDD Process] <defunct>
12441 pts/2 R+ 0:00 grep RDD
root@thegathering:/#
If i grep through filesystem i can find it nowhere. Duckduckgo’ing on it says that firefox starts it.
But how do i avoid firefox to start this one up again?
It is very obvious that RDD Process here was getting used for hacking type purposes.
After i killed it the video (in this case Within Temptation) ran further on youtube without problems.
How to avoid anyone managing getting ‘out of the box’ in firefox starting a proces which i can find nowhere which doesn’t show up in ‘ps’ and only is visible after i killed the process_id?
It seems stealthy type of thing. How is this possible in linux?
I design 3d printer here. I hope to sell for a billion dollar. How can i criminal prosecute the dude who decided this? (it’s not like there is nothing to steal here).
Что такое RDD в spark
Я не совсем понимаю что это значит. Это как данные (секционированные объекты), хранящиеся на жестком диске, если да, то почему RDD могут иметь пользовательские классы (такие как java, scala или python)
по этой ссылке: https://www.safaribooksonline.com/library/view/learning-spark/9781449359034/ch03.html в нем упоминается:
пользователи создают RDDs двумя способами: путем загрузки внешнего набора данных или распределение коллекции объектов (например, списка или набора) в их программа драйвера
Я действительно смущен пониманием RDD в целом и в отношении spark и hadoop.
может кто-нибудь помочь.
8 ответов
RDD-это, по сути, искровое представление набора данных, распределенных по нескольким машинам, с API, позволяющими вам действовать на нем. RDD может поступать из любого источника данных, например текстовых файлов, базы данных через JDBC и т. д.
РДУ отказоустойчивые параллельные структуры данных, которые позволяют пользователям явно сохраняйте промежуточные результаты в памяти, контролируйте их секционирование для оптимизации размещения данных и управление ими с помощью богатый набор операторов.
Если вы хотите получить полную информацию о том, что такое RDD, прочитайте одну из основных научных работ Spark,устойчивые распределенные наборы данных: отказоустойчивая абстракция для кластерных вычислений в памяти
RDD является логической ссылкой на dataset , который разделен на множество компьютеров-серверов в кластере. RDDs неизменяемы и самостоятельно восстанавливаются в случае сбоя.
dataset могут быть данные, загруженные извне пользователем. Это может быть файл json, csv-файл или текстовый файл без определенной структуры данных.
обновление: здесь статья описание внутренних органов RDD:
надеюсь, что это помогает.
формально RDD представляет собой секционированную коллекцию записей только для чтения. RDDs может быть создан только с помощью детерминированных операций либо (1) данных в стабильном хранилище, либо (2) других RDDs.
RDDs имеют следующие свойства —
неизменяемость и разделение: RDDs состоит из коллекции записей, которые секционированы. Раздел является базовой единицей параллелизма в RDD, и каждый раздел является одним логическим разделением данных, которое является неизменяемым и создается с помощью некоторых преобразований на существующих разделах.Неизменность помогает достичь согласованности в вычислениях.
пользователи могут определить свои собственные критерии для секционирования на основе ключей, на которых они хотят объединить несколько наборов данных, если это необходимо.
крупнозернистые операции: Крупнозернистый операции-это операции, которые применяются ко всем элементам в наборах данных. Например-карта, или фильтр, или операция groupBy, которая будет выполняться на всех элементах в разделе RDD.
Отказоустойчивость: Поскольку RDDs создаются по набору преобразований, он регистрирует эти преобразования, а не фактические данные.График этих преобразований для получения одного RDD называется графом Lineage.
в случае, если мы потеряем некоторый раздел RDD, мы можем воспроизвести преобразование на этом разделе в lineage выполните одно и то же вычисление, а не репликацию данных на нескольких узлах.Эта характеристика самое большое преимущество RDD, потому что она сохраняет много усилия в управлении данными и репликации и таким образом достигает более быстрых вычислений.
ленивых вычислений: Spark вычисляет RDDs лениво в первый раз, когда они используются в действии, чтобы он мог передавать преобразования. Таким образом, в приведенном выше примере RDD будет оцениваться только при действии count() вызванный.
настойчивость: Пользователи могут указать, какие RDDs они будут повторно использовать, и выбрать для них стратегию хранения (например, в памяти или на диске и т. д.)
Playing YouTube videos starts a process called "RDD Process" which uses a lot of my CPU and lags the player out until killed, at which point the video stops for a moment before resuming, unbuffered.
It's part of Firefox that is responsible for media decoding.
Nothing much you can do about it for now unless you use Firefox on wayland (which supports hardware video decoding iirc)