-
Notifications
You must be signed in to change notification settings - Fork 28
/
firefox-chromium.html
735 lines (653 loc) · 48.4 KB
/
firefox-chromium.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
<!DOCTYPE html>
<html lang=en>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="referrer" content="no-referrer">
<meta name="color-scheme" content="light dark">
<link rel="stylesheet" type="text/css" href="/styles.css">
<script src="/theme.js"></script>
<script type="module" src="/button.js"></script>
<title>Firefox and Chromium | Madaidan's Insecurities</title>
</head>
<body>
<button class="theme-toggle">🌓</button>
<h1>Firefox and Chromium</h1>
<p class="date"><em><time datetime="2022-03-19">Last edited: March 19th, 2022</time></em></p>
<p>
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. <br>
<br>
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.
</p>
<h2>Contents</h2>
<details>
<summary><a href="#sandboxing">1. Sandboxing</a></summary>
<a href="#site-isolation">1.1 Site Isolation</a> <br>
<a href="#windows-sandbox">1.2 Windows</a>
<details>
<summary><a href="#linux-sandbox">1.3 Linux</a></summary>
<a href="#linux-sandbox-escapes">1.3.1 Linux Sandbox Escapes</a> <br>
<a href="#seccomp-bpf">1.3.2 seccomp-bpf</a>
</details>
<a href="#android-sandbox">1.4 Android</a> <br>
<a href="#missing-processes">1.5 Missing Processes</a>
</details>
<details>
<summary><a href="#exploit-mitigations">2. Exploit Mitigations</a></summary>
<a href="#acg-cig">2.1 Arbitrary Code Guard and Code Integrity Guard</a> <br>
<details>
<summary><a href="#cfi">2.2 Control Flow Integrity</a></summary>
<a href="#forward-edge-cfi">2.2.1 Forward-edge CFI</a> <br>
<a href="#backward-edge-cfi">2.2.2 Backward-edge CFI</a> <br>
</details>
<a href="#untrusted-fonts-blocking">2.3 Untrusted Fonts Blocking</a> <br>
<a href="#jit-hardening">2.4 JIT Hardening</a> <br>
<details>
<summary><a href="#memory-allocator-hardening">2.5 Memory Allocator Hardening</a></summary>
<a href="#memory-partitioning">2.5.1 Memory Partitioning</a> <br>
<a href="#out-of-line-metadata">2.5.2 Out-of-line Metadata</a> <br>
<a href="#partitionalloc-other">2.5.3 Other</a> <br>
</details>
<a href="#auto-var-init">2.6 Automatic Variable Initialisation</a> <br>
</details>
<a href="#miscellaneous" class="nodropdown">3. Miscellaneous</a>
<br>
<a href="#security-researcher-views" class="nodropdown">4. Other Security Researchers' Views on Firefox</a>
<h2 id="sandboxing"><a href="#sandboxing">1. Sandboxing</a></h2>
<p>
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 <a
href="https://en.wikipedia.org/wiki/Principle_of_least_privilege">principle of least privilege</a>. 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. <br>
<br>
However, sandboxes are not black and white. Just having a sandbox doesn't do much if it's full of holes.
<a href="https://wiki.mozilla.org/Security/Sandbox">Firefox's sandbox</a> 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.
</p>
<h3 id="site-isolation"><a href="#site-isolation">1.1 Site Isolation</a></h3>
<p>
<a href="https://www.chromium.org/Home/chromium-security/site-isolation">Site isolation</a> is a security feature which was
<a href="https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html">introduced in Chromium in 2018</a>.
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. <a
href="https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/compromised-renderers.md">This ensures that
a renderer exploit from one website still cannot access the data from another</a>. In addition,
<a href="https://www.usenix.org/conference/usenixsecurity19/presentation/reis">site isolation is necessary for complete protection
against side-channel attacks like Spectre</a>. 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 <a href="https://developers.google.com/web/updates/2018/02/meltdown-spectre#high-resolution_timers">
reducing JavaScript timer accuracy</a>, are insufficient and do not address the root issue. As such, <a
href="https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/side-channel-threat-model.md">the only proper
mitigation is through site isolation</a>. <br>
<br>
Firefox fully rolled out their Fission project in <a href="https://www.mozilla.org/en-US/firefox/95.0/releasenotes/">Firefox 95</a>. 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 <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=1505832">numerous</a> <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1484019">
cross-site</a> <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1707955">leaks</a>, allowing a compromised content process to access
the data of another and bypass site isolation.
</p>
<h3 id="windows-sandbox"><a href="#windows-sandbox">1.2 Windows</a></h3>
<p>
Excluding the issue
of site isolation, only the Firefox sandbox on Windows is even comparable to the <a
href="https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox.md">Chromium sandbox</a>; however,
<a href="https://bugzilla.mozilla.org/buglist.cgi?quicksearch=win32k">it still lacks</a> <a
href="https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox.md#win32k_sys-lockdown">win32k lockdown</a>. Win32k is a set of
dangerous system calls in the NT kernel that expose a lot of attack surface and <a
href="https://github.com/microsoft/MSRC-Security-Research/blob/master/presentations/2018_10_DerbyCon/2018_10_DerbyCon_State_of%20_Win32k_Security.pdf">
has historically been the result of numerous vulnerabilities</a>, making it a frequent target for sandbox escapes. Microsoft aimed to lessen this risk
by introducing a feature that <a href="https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-process_mitigation_system_call_disable_policy">
allows a process to block access to these syscalls</a>, therefore massively reducing attack surface. <a
href="https://googleprojectzero.blogspot.com/2016/11/breaking-chain.html">Chromium implemented this feature in 2016</a> to strengthen the sandbox, but
Firefox has yet to follow suit — <a
href="https://searchfox.org/mozilla-central/rev/a5bf5d0720f9454687f500513ac82b0c8abce5a4/modules/libpref/init/StaticPrefList.yaml#10133">Firefox currently
only enables this in the socket process</a> (<a href="#missing-processes">which isn't enabled yet</a>).
</p>
<h3 id="linux-sandbox"><a href="#linux-sandbox">1.3 Linux</a></h3>
<h4 id="linux-sandbox-escapes"><a href="#linux-sandbox-escapes">1.3.1 Sandbox Escapes</a></h4>
<p>
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.
</p>
<ul>
<li class="lilist">
One example of such sandbox escape flaws is X11 — <a href="https://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html">X11
doesn't implement any GUI isolation</a>, which makes it <a href="https://mjg59.dreamwidth.org/42320.html">very easy to escape sandboxes with it</a>. 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, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1129492">it is exposed directly to the content process</a>.
</li>
<li class="lilist">
<a href="https://www.freedesktop.org/wiki/Software/PulseAudio/">PulseAudio</a> is a common sound server on Linux. However, <a
href="https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/AccessControl/">it was not written with isolation in mind</a>, making it
possible to escape sandboxes with it. Like X11, <a href="https://searchfox.org/mozilla-central/search?q=pulseaudio&path=security%2Fsandbox%2Flinux">Firefox
exposes this directly to the content process</a>, permitting another trivial sandbox escape, while <a
href="https://github.com/chromium/chromium/blob/master/services/audio/audio_sandbox_hook_linux.cc">Chromium only exposes it to a dedicated audio service</a>.
</li>
</ul>
<h4 id="seccomp-bpf"><a href="#seccomp-bpf">1.3.2 seccomp-bpf</a></h4>
<p>
<a href="https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html">seccomp-bpf</a> 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 <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1302711">there is very little filtering of ioctl calls</a> — <a
href="https://searchfox.org/mozilla-central/rev/9ae77e4ce3378bd683ac9a86b729ea6b6bd22cb8/security/sandbox/linux/SandboxFilter.cpp#1291">only TTY-related ioctls
are blocked in the content process</a>. 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, <a
href="https://github.com/chromium/chromium/search?q=path%3A%2Fsandbox+RestrictIoctl">Chromium permits only the few ioctls that are necessary in its sandbox</a>,
which reduces kernel attack surface by a considerable amount. In a similar fashion, <a href="https://kernsec.org/files/lss2015/vanderstoep.pdf">Android implemented
ioctl filtering in its application sandbox</a> for the same reasons, alongside various other projects with a focus on sandboxing.
</p>
<h3 id="android-sandbox"><a href="#android-sandbox">1.4 Android</a></h3>
<p>
On Android, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1530770">Firefox has implemented a multi-process architecture since 2021</a>; however, this is
still severely limited, and <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1565196">no sandboxing is enabled</a>. Whereas Chromium
uses the <a href="https://developer.android.com/guide/topics/manifest/service-element#isolated"><code>isolatedProcess</code> feature</a>, along with
<a href="https://github.com/chromium/chromium/blob/master/sandbox/linux/seccomp-bpf-helpers/baseline_policy_android.cc">a more restrictive seccomp-bpf filter</a>.
</p>
<h3 id="missing-processes"><a href="#missing-processes">1.5 Missing Processes</a></h3>
<p>
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.
</p>
<ul>
<li class="lilist">
On Linux, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1653444">Firefox has no separate GPU process</a>, meaning it cannot be independently sandboxed.
<a href="https://wiki.mozilla.org/Security/Sandbox/Process_model#GPU_Process">This process exists on Windows</a>, although <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=1347710">the sandboxing for it is still not enabled</a>.
</li>
<li class="lilist">
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1322426">Firefox does not yet have a separate socket process for network operations</a> — this process <a
href="https://wiki.mozilla.org/Security/Sandbox#Socket_Process">only exists in Nightly and doesn't include anything other than WebRTC code</a>, unlike <a
href="https://chromium.googlesource.com/chromium/src/+/refs/heads/main/services/network/README.md">Chromium's dedicated network service</a>.
</li>
<li class="lilist">
Firefox also does not have an audio process, whereas <a href="https://docs.google.com/document/d/1s_Fd1WRDdpb5n6C2MSJjeC3fis6hULZwfKMeDd4K5tI/">Chromium has a
dedicated audio service</a>. The lack of such a process in Firefox means that audio functionality is merged into the content process, which is the cause of the
<a href="#linux-sandbox-escapes">PulseAudio sandbox escape vector on Linux systems</a>.
</li>
<li class="lilist">
Further examples include text-to-speech, printing backend and compositor, speech recognition, proxy resolver and <a
href="https://github.com/chromium/chromium/blob/master/sandbox/policy/sandbox_type.cc">more</a>.
</li>
</ul>
<p>
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.
</p>
<h2 id="exploit-mitigations"><a href="#exploit-mitigations">2. Exploit Mitigations</a></h2>
<p>
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. <br>
<br>
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 <a href="https://bugzilla.mozilla.org/home">Mozilla's own bug tracker</a> for further examples.
</p>
<h3 id="acg-cig"><a href="#acg-cig">2.1 Arbitrary Code Guard and Code Integrity Guard</a></h3>
<p>
A very common exploit technique is that during exploitation of a <a href="https://en.wikipedia.org/wiki/Buffer_overflow">buffer overflow</a>
vulnerability, an attacker injects their own malicious code (known as <a href="https://en.wikipedia.org/wiki/Shellcode">shellcode</a>) into a
part of memory and causes the program to execute it by overwriting critical data, such as <a href="https://en.wikipedia.org/wiki/Return_statement">
return addresses</a> and <a href="https://en.wikipedia.org/wiki/Function_pointer">function pointers</a>, to hijack the control flow and point to the
aforementioned shellcode, thereby gaining control over the program. <br>
<br>
The industry eventually evolved to mitigate this style of attacks by <a href="https://en.wikipedia.org/wiki/Executable_space_protection">marking
writable areas of memory as non-executable</a> 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 <a href="https://en.wikipedia.org/wiki/Return-oriented_programming">Return-Oriented
Programming</a> (ROP) or <a href="https://www.csc2.ncsu.edu/faculty/xjiang4/pubs/ASIACCS11.pdf">Jump-Oriented Programming</a> (JOP). <br>
<br>
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 <code>mprotect</code> or <code>VirtualAlloc</code>), consequently allowing it to be executed. <a
href="https://blogs.windows.com/msedgedev/2017/02/23/mitigating-arbitrary-native-code-execution/">Windows 10 implemented a mitigation</a> known as <a
href="https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/exploit-protection-reference?view=o365-worldwide#arbitrary-code-guard">
Arbitrary Code Guard</a> (ACG), which mitigates this by ensuring that all executable memory pages are immutable and can never be made writable. <br>
<br>
Another mitigation known as <a
href="https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/exploit-protection-reference?view=o365-worldwide#code-integrity-guard">Code
Integrity Guard</a> (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. <br>
<br>
In 2017, <a href="https://github.com/chromium/chromium/commit/21a5ba4cfdbafc3b0908f9af75c0de30b03d47ec">Chromium implemented support for ACG and CIG</a>
as <code>MITIGATION_DYNAMIC_CODE_DISABLE</code> and <code>MITIGATION_FORCE_MS_SIGNED_BINS</code>, but Firefox has yet to implement comparable support for
either <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1381050">ACG</a> or <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1378417">CIG</a>.
Currently, <a
href="https://searchfox.org/mozilla-central/rev/a5bf5d0720f9454687f500513ac82b0c8abce5a4/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp#1146">
Firefox only enables ACG and CIG in the socket process</a> (<a href="#missing-processes">which isn't enabled yet</a>) and <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=1620114">CIG in the RDD process</a>. <br>
<br>
However, Chromium's application of ACG is still currently limited due to the inherent incompatibility with JIT engines, which dynamically generate code
(<a href="#jit-hardening">JIT is explained in further detail below</a>). <a
href="https://github.com/chromium/chromium/search?q=MITIGATION_DYNAMIC_CODE_DISABLE">ACG is primarily enabled in relatively minor processes</a>, 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
<a href="https://v8.dev/blog/jitless">JITless mode</a> is enabled, then Chromium also
<a href="https://github.com/chromium/chromium/commit/9475a21dd27b4a487f410e62a167ff86b4d35287">enables ACG in the renderer process</a>; Firefox does not
enable ACG in the renderer regardless of JIT.
</p>
<table>
<thead>
<tr>
<th colspan="3">ACG</th>
</tr>
</thead>
<tbody>
<tr>
<td></td>
<td class="identifier-row">Chromium</td>
<td class="identifier-row">Firefox</td>
</tr>
<tr>
<td class="identifier-column">Renderer/Content</td>
<td> N*</td>
<td>N</td>
</tr>
<tr>
<td class="identifier-column">GPU</td>
<td>N</td>
<td>N</td>
</tr>
<tr>
<td class="identifier-column">RDD</td>
<td>N</td>
<td>N</td>
</tr>
<tr>
<td class="identifier-column">Extensions</td>
<td>N</td>
<td>N</td>
</tr>
<tr>
<td class="identifier-column">Network/Socket</td>
<td> N*</td>
<td><a href="#missing-processes">N/A</a></td>
</tr>
<tr>
<td class="identifier-column">Audio</td>
<td>Y</td>
<td><a href="#missing-processes">N/A</a></td>
</tr>
</tbody>
</table>
<p style="font-style: italic;">
* <a href="https://github.com/chromium/chromium/commit/9475a21dd27b4a487f410e62a167ff86b4d35287">Chromium enables ACG in the renderer process
when running in JITless mode</a>. <br>
* <a href="https://github.com/chromium/chromium/blob/fd8a8914ca0183f0add65ae55f04e287543c7d4a/sandbox/policy/win/sandbox_win.cc#L1084">Chromium
enables ACG in the network process if the <code>NetworkServiceSandbox</code> feature is enabled.</a>
</p>
<table>
<thead>
<tr>
<th colspan="3">CIG</th>
</tr>
</thead>
<tbody>
<tr>
<td></td>
<td class="identifier-row">Chromium</td>
<td class="identifier-row">Firefox</td>
</tr>
<tr>
<td class="identifier-column">Renderer/Content</td>
<td>Y</td>
<td>N</td>
</tr>
<tr>
<td class="identifier-column">GPU</td>
<td>Y</td>
<td>N</td>
</tr>
<tr>
<td class="identifier-column">RDD</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td class="identifier-column">Extensions</td>
<td>Y</td>
<td>N</td>
</tr>
<tr>
<td class="identifier-column">Network/Socket</td>
<td> N*</td>
<td><a href="#missing-processes">N/A</a></td>
</tr>
<tr>
<td class="identifier-column">Audio</td>
<td>Y</td>
<td><a href="#missing-processes">N/A</a></td>
</tr>
</tbody>
</table>
<p style="font-style: italic;">
* <a href="https://github.com/chromium/chromium/commit/3249aa3c8dce41fdbcf3093bdd08a1793113c0fd">Chromium can optionally enable CIG in the network
process if the <code>NetworkServiceCodeIntegrity</code> feature is enabled</a>.
</p>
<h3 id="cfi"><a href="#cfi">2.2 Control Flow Integrity</a></h3>
<p>
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 <a href="https://blog.trailofbits.com/2016/10/17/lets-talk-about-cfi-clang-edition/">Control Flow Integrity</a> (CFI), which severely restricts the
gadgets an attacker is able to make use of, thus disrupting their chain. <br>
<br>
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.
</p>
<h4 id="forward-edge-cfi"><a href="#forward-edge-cfi">2.2.1 Forward-edge CFI</a></h4>
<p>
On Linux, Android and ChromeOS, <a href="https://www.chromium.org/developers/testing/control-flow-integrity">Chromium enables Clang's fine-grained, forward-edge
CFI</a>. On Windows, it <a href="https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox.md#Process-mitigation-policies">enables the
weaker, coarse-grained, forward-edge Control Flow Guard</a> (CFG), although <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=507755">Chromium has
been investigating deploying Clang CFI on Windows</a>. <br>
<br>
Mozilla has been <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=510629">planning to implement forward-edge CFI for a while</a> but has yet to make significant
progress. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1438868">Firefox only enables CFG on Windows</a>; 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.
</p>
<h4 id="backward-edge-cfi"><a href="#backward-edge-cfi">2.2.2 Backward-edge CFI</a></h4>
<p>
As for backward-edge protection, in 2021, <a href="https://security.googleblog.com/2021/05/enabling-hardware-enforced-stack.html">Chrome implemented shadow stacks
using Intel's Control-flow Enforcement Technology (CET)</a>. <a href="https://en.wikipedia.org/wiki/Shadow_stack">Shadow stacks</a> 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. <a
href="https://github.com/chromium/chromium/blob/12c232c43ce7324d308afab5349b38b7707d8226/content/public/common/sandboxed_process_launcher_delegate.cc#L38">Chromium
automatically enables this for all processes</a> 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, <a href="https://github.com/chromium/chromium/blob/12c232c43ce7324d308afab5349b38b7707d8226/content/browser/renderer_host/renderer_sandboxed_process_launcher_delegate.cc#L107">
CET is enabled in the renderer when V8 is running in JITless mode</a>, similar to ACG, as mentioned above. <br>
<br>
Stable releases of Firefox currently lack any backward-edge protection. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1626950">CET support has only been implemented
in Firefox Nightly</a>, but <a href="https://searchfox.org/mozilla-central/rev/c3894603d85d2e45dbebf9697f1951ab998b22cb/modules/libpref/init/StaticPrefList.yaml#11673">this
still has incomplete coverage</a>, and there is no protection for the renderer/content process regardless of the JIT engine's status.
</p>
<h3 id="untrusted-fonts-blocking"><a href="#untrusted-fonts-blocking">2.3 Untrusted Fonts Blocking</a></h3>
<p>
Untrusted fonts have historically been a common source of vulnerabilities within Windows. As such, Windows includes a mitigation to <a
href="https://docs.microsoft.com/en-us/troubleshoot/windows-client/shell-experience/feature-to-block-untrusted-fonts">block untrusted fonts from specific processes
to reduce attack surface</a>. <a href="https://github.com/chromium/chromium/commit/441d852dbcb7b9b31328393c7e31562b1e268399">Chromium added support for this in 2016</a>
in the form of <code>MITIGATION_NONSYSTEM_FONT_DISABLE</code> and enabled it for most child processes; however, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1689128">
Firefox has yet to enable this in any</a>.
</p>
<table>
<thead>
<tr>
<th colspan="3">Untrusted Font Blocking</th>
</tr>
</thead>
<tbody>
<tr>
<td></td>
<td class="identifier-row">Chromium</td>
<td class="identifier-row">Firefox</td>
</tr>
<tr>
<td class="identifier-column">Renderer/Content</td>
<td>Y</td>
<td>N</td>
</tr>
<tr>
<td class="identifier-column">GPU</td>
<td>Y</td>
<td>N</td>
</tr>
<tr>
<td class="identifier-column">RDD</td>
<td>Y</td>
<td>N</td>
</tr>
<tr>
<td class="identifier-column">Extensions</td>
<td>Y</td>
<td>N</td>
</tr>
<tr>
<td class="identifier-column">Network/Socket</td>
<td>N</td>
<td><a href="#missing-processes">N/A</a></td>
</tr>
<tr>
<td class="identifier-column">Audio</td>
<td>Y</td>
<td><a href="#missing-processes">N/A</a></td>
</tr>
</tbody>
</table>
<h3 id="jit-hardening"><a href="#jit-hardening">2.4 JIT Hardening</a></h3>
<p>
All mainstream browsers include a <a href="https://en.wikipedia.org/wiki/Just-in-time_compilation">JIT compiler</a> 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 <a href="https://en.wikipedia.org/wiki/W%5EX">W^X</a> violation, <a href="#acg-cig">as discussed above</a>. In an attempt
to lessen the security risks posed by this feature without sacrificing the performance gains,
<a href="https://www.ndss-symposium.org/wp-content/uploads/2017/09/ndss2017_10-4_Lian_paper.pdf">browsers have adopted JIT hardening techniques</a> to make exploiting
the JIT compiler more difficult. <a href="https://github.com/struct/research/blob/master/Attacking_Clientside_JIT_Compilers_Paper.pdf">In a study on attacking JIT
compilers published by Chris Rohlf</a>, the hardening techniques implemented in various JIT engines were analysed and compared. This study demonstrated that the JIT
engine used in Chromium (<a href="https://v8.dev/">V8</a>) applies substantially better protections than the engine used in Firefox (<a
href="https://wiki.mozilla.org/JaegerMonkey">JaegerMonkey</a>). In particular, the mitigations which Chromium implemented that Firefox did not use include:
</p>
<ul>
<li>Guard pages.</li>
<li>Page randomization.</li>
<li>Constant blinding.</li>
<li>Allocation restrictions.</li>
<li>NOP insertions.</li>
<li>Random code base offset.</li>
</ul>
<p>
Since the publication of the paper, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=677272">Firefox has made limited progress on adopting these techniques</a>.
Examples of lacking mitigations include <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1376819">constant blinding</a> and <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=729824">NOP insertion</a>. On the other hand, <a
href="https://www.usenix.org/system/files/conference/woot18/woot18-paper-gawlik.pdf">JIT hardening mitigations are not particularly strong</a> and can often be bypassed,
so these may not be as consequential as other security features. <br>
<br>
Firefox did attempt to harden the JIT engine by adding a so-called <a href="https://jandemooij.nl/blog/wx-jit-code-enabled-in-firefox/">"W^X JIT"</a>, but this fails to
hinder actual exploits, as <a href="https://www.ndss-symposium.org/wp-content/uploads/2017/09/09_2_2.pdf">it is vulnerable to a race window</a> 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 <code>ExecutableAllocator::makeExecutable</code> or
<code>mprotect</code> / <code>VirtualAlloc</code> in the C library. Furthermore, <a
href="https://github.com/v8/v8/blob/fb39eec368c1433d01ec38775be5fbdd7ba8c015/src/flags/flag-definitions.h#L1260">V8 has also adopted a similar, equally futile mitigation</a>,
so even if this were useful, it's not an advantage over Chromium. <br>
<br>
Something similar to Safari's <a href="https://googleprojectzero.blogspot.com/2020/09/jitsploitation-three.html">"Bulletproof JIT"</a>
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, <a href="https://www.ndss-symposium.org/wp-content/uploads/2017/09/09_2_2.pdf">secure dynamic code generation</a> (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. <br>
<br>
<a href="https://archive.fo/9aBLk">As PaX Team noted in 2015</a>: <br>
<br>
</p>
<p class="quote">
> but for this to be safe, the RW mapping should be in a separate process. <br>
<br>
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 . <br>
[...]<br>
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). <br>
<br>
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. <br>
<br>
in summary, this is a half-baked security measure that is DOA.
</p>
<h3 id="memory-allocator-hardening"><a href="#memory-allocator-hardening">2.5 Memory Allocator Hardening</a></h3>
<p>
Furthermore, Firefox lacks a hardened memory allocator. Firefox currently uses <a href="https://searchfox.org/mozilla-central/source/memory/build/mozjemalloc.cpp">
mozjemalloc</a>, which is a fork of <a href="https://github.com/jemalloc/jemalloc">jemalloc</a>. Jemalloc is a performance-oriented
memory allocator — it does not have a focus on security, which makes it <a
href="https://media.blackhat.com/bh-us-12/Briefings/Argyoudis/BH_US_12_Argyroudis_Exploiting_the_%20jemalloc_Memory_%20Allocator_Slides.pdf">
very prone to exploitation</a>. Mozjemalloc does add on a few security features to jemalloc which are useful, but <a
href="https://lists.torproject.org/pipermail/tor-dev/2019-August/013990.html">they are not enough to
fix the issues present in the overall architecture of the allocator</a>. Chromium instead uses <a
href="https://chromium.googlesource.com/chromium/src/+/master/base/allocator/partition_allocator/PartitionAlloc.md">
PartitionAlloc</a> (throughout the entire codebase due to <a href="https://blog.chromium.org/2021/04/efficient-and-safe-allocations-everywhere.html">PartitionAlloc-Everywhere</a>), which is
substantially more hardened than mozjemalloc is. <br>
<br>
In comparison to mozjemalloc, a few examples of <a href="https://struct.github.io/partition_alloc.html">the security features present in PartitionAlloc</a> which do not exist in mozjemalloc
are detailed below.
</p>
<h4 id="memory-partitioning"><a href="#memory-partitioning">2.5.1 Memory Partitioning</a></h4>
<p>
<a href="https://labs.f-secure.com/archive/isolated-heap-friends-object-allocation-hardening-in-web-browsers/">Memory partitioning</a> 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. <br>
<br>
Chromium's PartitionAlloc was explicitly designed with this mitigation in mind (hence the name); <a
href="https://chromium.googlesource.com/chromium/src/+/master/base/allocator/partition_allocator/PartitionAlloc.md#security">strong memory partitioning with no reused memory between partitions
is one of PartitionAlloc's core goals</a>. <br>
<br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1052575">Firefox's mozjemalloc also eventually implemented some support for partitioning</a>. However, <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=1446046">memory is reused across partitions</a>, 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
<a href="https://twitter.com/dguido/status/803838692645335040">was possible due to the lack of memory partitioning</a>.
</p>
<h4 id="out-of-line-metadata"><a href="#out-of-line-metadata">2.5.2 Out-of-line Metadata</a></h4>
<p>
<a href="https://scarybeastsecurity.blogspot.com/2017/05/further-hardening-glibc-malloc-against.html">Traditional heap exploitation techniques often rely on corrupting the memory allocator
metadata</a>. <a href="https://chromium.googlesource.com/chromium/src/+/master/base/allocator/partition_allocator/PartitionAlloc.md#security">PartitionAlloc stores most metadata out-of-line
in a dedicated region</a> (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. <br>
<br>
Unlike PartitionAlloc, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1446045">mozjemalloc currently places heap metadata in-line with allocations</a>. As such, the aforementioned
techniques are still possible and allocator metadata is easier to corrupt. <br>
<br>
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; <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1446040">this is another security feature that mozjemalloc lacks</a>.
</p>
<h4 id="partitionalloc-other"><a href="#partitionalloc-other">2.5.3 Other</a></h4>
<p>
PartitionAlloc has a <a href="https://github.com/chromium/chromium/blob/44b86c998d26d0072bc48d63b3d0f5570ee50f31/base/allocator/partition_allocator/partition_page.h#L688-L689">naive check for
double frees</a>, but <a href="https://blog.infosectcbr.com.au/2020/05/double-frees-in-chromes-partition-alloc.html">it isn't difficult to bypass</a>, so it's not a major feature. <br>
<br>
More importantly, PartitionAlloc is working on many promising upcoming security features, such as their <a href="https://docs.google.com/presentation/d/1QvfZXx5HdUl0IdkBcrx-NM0ua-PVcTi2jNx0Sf-n8Fo/">
MiraclePtr and *Scan</a> projects to effectively mitigate most use-after-free exploits.
</p>
<h3 id="auto-var-init"><a href="#auto-var-init">2.6 Automatic Variable Initialisation</a></h3>
<p>
One of the most common classes of memory corruption vulnerabilities is <a href="https://en.wikipedia.org/wiki/Uninitialized_variable">uninitialised memory</a>. Clang has an option to
<a href="https://reviews.llvm.org/D54604">automatically initialise stack variables</a> with either zero or a specific pattern, thus mitigating this class of vulnerabilities for the stack. <a
href="https://chromium.googlesource.com/chromium/src.git/+/7d38bae3ef691d5091b6d4d7973a9b4d2cd85eb2/build/config/compiler/BUILD.gn#125">Chromium enables this by default on all platforms except
Android</a>, whereas <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1546873">Firefox only enables it in debugging builds</a> for uncovering bugs and is not used in production to mitigate
exploits. <br>
<br>
As for the heap, both PartitionAlloc and mozjemalloc zero-fill allocations, so they are equivalent in that regard.
</p>
<h2 id="miscellaneous"><a href="#miscellaneous">3. Miscellaneous</a></h2>
<p>
Firefox <a href="https://wiki.mozilla.org/Oxidation">does have some parts written in Rust, a memory safe language</a>,
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 <a href="https://www.chromium.org/Home/chromium-security/memory-safety">Chromium is working on
switching to memory safe languages too</a>. <br>
<br>
Additionally, writing parts in a memory safe language does not necessarily improve security and may even <em>degrade</em> 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, <a href="https://www.cs.ucy.ac.cy/~eliasathan/papers/tops20.pdf">those features may be bypassed by abusing the other language</a>. 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, <a href="https://opensrcsec.com/open_source_security_announces_rust_gcc_funding">
compilers generally don't support this</a>, excluding <a href="https://msrc-blog.microsoft.com/2020/08/17/control-flow-guard-for-clang-llvm-and-rust/">
Windows' Control Flow Guard support in Clang</a>. <br>
<br>
Firefox also uses <a href="https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/">RLBox</a>, but <a
href="https://searchfox.org/mozilla-central/rev/e3ac5a25db15a6ec1636a1bb317b304b75a0bc95/security/rlbox/moz.build">this is currently only used to
sandbox five libraries</a>, which again, is not anything substantial and is not a replacement for a fine-grained sandboxing architecture covering the
browser as a whole.
</p>
<h2 id="security-researcher-views"><a href="#security-researcher-views">4. Other Security Researchers' Views on Firefox</a></h2>
<p>
Many security experts also share these views about Firefox, and a few examples are listed below:
</p>
<ul>
<li class="lilist">
thegrugq, information security researcher: <br>
<a href="https://medium.com/@thegrugq/tor-and-its-discontents-ef5164845908">Tor and its Discontents</a>
</li>
<li class="lilist">
Kenn White, security researcher: <br>
<a href="https://twitter.com/kennwhite/status/804142071133126656">https://twitter.com/kennwhite/status/804142071133126656</a>
</li>
<li class="lilist">
PaXTeam, developer of PaX: <br>
<a href="https://archive.fo/9aBLk">https://archive.fo/9aBLk</a>
</li>
<li class="lilist">
Daniel Micay, lead developer of GrapheneOS: <br>
<a href="https://grapheneos.org/usage#web-browsing">https://grapheneos.org/usage#web-browsing</a>
</li>
<li class="lilist">
Matthew Garrett, Linux developer: <br>
<a href="https://news.ycombinator.com/item?id=13800323">https://news.ycombinator.com/item?id=13800323</a>
</li>
<li class="lilist">
Dan Guido, CEO of Trail of Bits: <br>
<a href="https://news.ycombinator.com/item?id=13623735">https://news.ycombinator.com/item?id=13623735</a>
</li>
<li class="lilist">
Theo de Raadt, lead developer of OpenBsd: <br>
<a href="https://marc.info/?l=openbsd-misc&m=152872551609819&w=2">https://marc.info/?l=openbsd-misc&m=152872551609819&w=2</a>
</li>
<li class="lilist">
Thomas Ptacek, co-founder of Latacora and Matasano Security: <br>
<a href="https://twitter.com/tqbf/status/930807512609296384">https://twitter.com/tqbf/status/930807512609296384</a>, <br>
<a href="https://twitter.com/tqbf/status/930860544927649792">https://twitter.com/tqbf/status/930860544927649792</a>, <br>
<a href="https://twitter.com/tqbf/status/830511154950766595">https://twitter.com/tqbf/status/830511154950766595</a>
</li>
<li class="lilist">
qwertyoruiopz, iOS exploit developer: <br>
<a href="https://twitter.com/qwertyoruiopz/status/805887567493271556">https://twitter.com/qwertyoruiopz/status/805887567493271556</a>, <br>
<a href="https://twitter.com/qwertyoruiopz/status/730704655748075520">https://twitter.com/qwertyoruiopz/status/730704655748075520</a>
</li>
<li class="lilist">
John Wu, Android security engineer: <br>
<a href="https://twitter.com/topjohnwu/status/1105739918444253184">https://twitter.com/topjohnwu/status/1105739918444253184</a>, <br>
<a href="https://twitter.com/topjohnwu/status/1455606288419733505">https://twitter.com/topjohnwu/status/1455606288419733505</a>
</li>
<li class="lilist">
Chris Rohlf, security engineer: <br>
<a href="https://twitter.com/chrisrohlf/status/1455549993536966671">https://twitter.com/chrisrohlf/status/1455549993536966671</a>
</li>
<li class="lilist">
Matthew Green, cryptographer at Johns Hopkins University: <br>
<a href="https://twitter.com/matthew_d_green/status/830488564672626690">https://twitter.com/matthew_d_green/status/830488564672626690</a>
</li>
<li class="lilist">
Bruno Keith, security researcher at Dataflow Security: <br>
<a href="https://twitter.com/bkth_/status/1265971734777380865">https://twitter.com/bkth_/status/1265971734777380865</a>
</li>
<li class="lilist">
Niklas Baumstark, security researcher at Dataflow Security: <br>
<a href="https://twitter.com/_niklasb/status/1131129708073107456">https://twitter.com/_niklasb/status/1131129708073107456</a>
</li>
<li class="lilist">
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, <a href="https://twitter.com/paxteam/status/730902448018231300">
RAP can be applied to Chromium with relatively little effort</a>): <br>
<a href="https://gitlab.torproject.org/tpo/applications/tor-browser/-/wikis/Hardening">https://gitlab.torproject.org/tpo/applications/tor-browser/-/wikis/Hardening</a>
</li>
<li class="lilist">
Alex Gaynor, former Firefox security engineer and sandboxing lead: <br>
<a href="https://news.ycombinator.com/item?id=22342352">https://news.ycombinator.com/item?id=22342352</a>
</li>
</ul>
<a class="back" href="/index.html">Go back</a>
</body>
</html>