Opened 2 years ago

Closed 20 months ago

Last modified 20 months ago

#22692 closed enhancement (fixed)

Backport Linux content sandboxing from Firefox 54

Reported by: jld Owned by: tbb-team
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Major Keywords: GeorgKoppen201709, TorBrowserTeam201709R, tbb-backported
Cc: arthuredelstein, mcs, brade, saint, boklm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Tor Browser 7 is based on Firefox ESR 52, so it doesn't have content process sandboxing on Linux; that wasn't enabled for non-Nightly builds until 54. It's possible to configure with --enable-content-sandbox, but there are some bug fixes and improvements that should be backported. I'm told there's interest in doing that, so I came up with a list of patches (which merge cleanly, so I also ran some basic tests).

First, a warning: The sandboxing isn't very strong yet, especially for the threats that Tor Browser deals with: it still allows reading any file and doing arbitrary socket and connect calls, for example, so there's probably a way for a determined attacker to get a generic sandbox escape, and it definitely allows obtaining PII such as MAC addresses.

The short version:

The long version, as a list of Git commit identifiers from the gecko-dev repository (I don't know if there's a way to map these to Hg besides manually searching for commit messages), with vague descriptions:

2f25df5d1e7405ae76a15fb1c16bc3dd17d6bd98 prlimit64
f004938bbb928d3d9d04e119c6d448de4808f1d7 string split for pref
0d2bf66dfdb9601baf8cda464db66dc5773f1758 syscall allowed-list pref
5de2e3d5f6795f315a7e98319e4845e173b96ad8 vector fix for pref
eb0d19601af5af2228f7069243044f8ff4c5be73 crash-on-error flag
f2fa27edcadaa6ff38cbc16216b4cc63d438ae42 reporter part 1
f0666046d67d7d384eb458506e472091822c198a reporter part 2
6e97575e73b58a2ddcf76b244a93e4606d686a17 reporter part 3
7d9acbdacefe00cca9f9eaf8144900d29fa16d9b less networking
3c4e5389537a6841080e2e50390af2174e2d4f5c unbreak a11y (???)
f6b03fa2606c2892ffc903967eb6d7eab0a763a6 socketpair workaround
4821de2b5839e3f33d4ac647262d5d5255a71708 enable on non-nightly
dc7a177384f8f7acb94654b81c1af45b427d9260 gdbinit signal change
8f8a9f525559c6611de13fe5264753e5d62fa85b test "todo" fix

The most important part is the patch from bug 1286865 that makes unexpected syscalls just fail instead of crashing on non-Nightly builds ("crash-on-error flag", above). There are two big optional pieces: the three patches from bugs 1330326 and 1335323 that add a pref that's a list of additional syscall numbers to allow (to make it easier to deal with system libraries doing unexpected things), and the three other patches from bug 1286865 that expose a log of rejected syscalls in about:support (the "reporter"; it will still log to stderr without those).

The patch I've labelled "unbreak a11y" (which allows accept4) might not be necessary; I think we still disable e10s on non-Nightly if accessibility tools are in use. Alternately, commit 293bbaf3e964 from bug 1361338 could be used instead but I haven't tried it on 52.

The one thing I know this breaks is WebRTC getting local network addresses (see bugs 1345511, 1375122, and 1322506 for background; note that there are other ways of getting that info that aren't blocked yet), but Tor Browser disables WebRTC. Similarly, I've left out the part of bug 1286865 that submits Telemetry about rejected syscalls. There are also some patches I omitted where returning an error won't break anything, or where it's related to a feature (like WebAssembly) that's not on 52 ESR.

Hopefully that explains things well enough; let me know if anything needs more clarification.

Child Tickets

Attachments (1)

0001-Bug-22692-Don-t-use-mremap-in-selfrando-code.patch (1.4 KB) - added by gk 21 months ago.

Download all attachments as: .zip

Change History (24)

comment:1 Changed 2 years ago by gk

Cc: arthuredelstein mcs brade added
Keywords: TorBrowserTeam201706 added
Priority: MediumVery High
Severity: NormalMajor

Thanks jld, that's really helpful and appreciated. Given the complexity of this backport we should test it in some alpha builds I guess starting with the next one. Putting it on our agenda.

comment:2 Changed 2 years ago by cypherpunks

Whoa, so are you in business of backporting sandbox level 2? Then for other platforms too. Also are you going to do cherry-picking from the trunk?

comment:3 Changed 2 years ago by saint

Cc: saint added

comment:4 Changed 23 months ago by gk

Keywords: TorBrowserTeam201707 added; TorBrowserTeam201706 removed

Moving Tickets to July 2017.

comment:5 Changed 23 months ago by gk

Keywords: GeorgKoppen201707 added

comment:6 Changed 22 months ago by gk

Keywords: TorBrowserTeam201708 added; TorBrowserTeam201707 removed

Moving our Tickets to August.

comment:7 Changed 22 months ago by gk

Keywords: GeorgKoppen201708 added; GeorgKoppen201707 removed

Moving my tickets to August.

comment:8 in reply to:  2 Changed 22 months ago by gk

Replying to cypherpunks:

Whoa, so are you in business of backporting sandbox level 2? Then for other platforms too. Also are you going to do cherry-picking from the trunk?

We are in the business of getting content sandboxing on Linux going at all. ESR 52 does not have that by default. We are better off on macOS and we have #16010 for Windows. Once we have content sandboxing running on all supported platforms we can think about tightening the policies by backporting (more) patches.

comment:9 Changed 21 months ago by gk

Applying all of the patches (or just the non-optional ones according to comment:description) leads to crashes pretty easily (e.g. on However, that does not seem to be caused by Firefox but rather by selfrando. Before crashing I see something like

Sandbox: seccomp sandbox violation: pid 5231, tid 5231, syscall 25, args 140268925878272 135 199 1 0 18446744073709551612

in my terminal which is not happening without selfrando. I guess selfrando is not happy about its mremap getting blocked by the sandbox? The accompanying stack trace of the content process crash is:

#0  0x00007f5862230fa6 in Vector<unsigned char*>::append(unsigned char* const&) (val=<synthetic pointer>: <optimized out>, this=0x7fffffffbd30)
    at src/RandoLib/RandoLib.h:129
#1  0x00007f5862230fa6 in os::Module::<lambda(const trap_reloc_t&)>::operator() (trap_reloc=<synthetic pointer>..., __closure=<synthetic pointer>)
    at src/RandoLib/posix/OSImpl.cpp:641
#2  0x00007f5862230fa6 in TrapInfo::for_all_relocations<os::Module::read_got_relocations(const TrapInfo*)::<lambda(const trap_reloc_t&)> >(os::Module::<lambda(const trap_reloc_t&)>) const (this=this@entry=0x7fffffffbc30, func=..., func@entry=...)
    at src/TrapInfo/TrapInfo.h:672
#3  0x00007f58622321ec in os::Module::read_got_relocations(TrapInfo const*) (this=this@entry=0x7fffffffbcb0, trap_info=trap_info@entry=0x7fffffffbc30)
    at src/RandoLib/posix/OSImpl.cpp:642
#4  0x00007f58622326dc in os::Module::for_all_exec_sections(bool, void (*)(os::Module const&, os::Module::Section const&, TrapInfo&, bool, void*), void*) (this=0x7fffffffbcb0, self_rando=true, callback=0x7f586222e580 <randomize_exec_section(os::Module const&, os::Module::Section const&, TrapInfo&, bool, void*)>, callback_arg=0x0)
    at src/RandoLib/posix/OSImpl.cpp:422
#5  0x00007f586222e750 in RandoMain(os::Module::Handle) (asm_module=0x7fffffffbd70)
    at src/RandoLib/RandoLib.cpp:599
#6  0x00007f58622359cb in Linux_EntryPointImpl ()
    at src/RandoLib/posix/EntryPoint.c:70
#7  0x00007f5862235883 in _TRaP_Linux_EntryPoint_init ()
    at /home/thomas/Arbeit/Tor/debugging/22692/tor-browser_en-US/Browser/
#8  0x00007f5862210748 in  ()
    at /home/thomas/Arbeit/Tor/debugging/22692/tor-browser_en-US/Browser/
#9  0x0000000000000009 in  ()
#10 0x00007fffffffddf8 in  ()
#11 0x00007f589240385a in call_init (l=0x7f5862182800, argc=-16824, 
    argc@entry=9, argv=argv@entry=0x7fffffffdda8, env=env@entry=0x7fffffffddf8)
    at dl-init.c:58
#12 0x00007f58924039ab in call_init (env=0x7fffffffddf8, argv=0x7fffffffdda8, argc=9, l=<optimized out>) at dl-init.c:30
#13 0x00007f58924039ab in _dl_init (main_map=main_map@entry=0x7f5862182800, argc=9, argv=0x7fffffffdda8, env=0x7fffffffddf8) at dl-init.c:120
#14 0x00007f5892407f58 in dl_open_worker (a=a@entry=0x7fffffffc100)
    at dl-open.c:575
#15 0x00007f5892403744 in _dl_catch_error (objname=objname@entry=0x7fffffffc0f0, errstring=errstring@entry=0x7fffffffc0f8, mallocedp=mallocedp@entry=0x7fffffffc0ef, operate=operate@entry=0x7f5892407b70 <dl_open_worker>, args=args@entry=0x7fffffffc100)
    at dl-error.c:187
#16 0x00007f5892407709 in _dl_open (file=0x7f58607fb820 "/home/thomas/Arbeit/Tor/debugging/22692/tor-browser_en-US/Browser/", mode=-2147483646, caller_dlopen=0x7f589257fb9d <PR_dtoa+3405>, nsid=-2, argc=<optimized out>, argv=<optimized out>, env=0x7fffffffddf8) at dl-open.c:660
#17 0x00007f588be8cee9 in dlopen_doit (a=a@entry=0x7fffffffc330) at dlopen.c:66
#18 0x00007f5892403744 in _dl_catch_error (objname=0x7f58835531f0, errstring=0x7f58835531f8, mallocedp=0x7f58835531e8, operate=0x7f588be8ce90 <dlopen_doit>, args=0x7fffffffc330) at dl-error.c:187
#19 0x00007f588be8d531 in _dlerror_run (operate=operate@entry=0x7f588be8ce90 <dlopen_doit>, args=args@entry=0x7fffffffc330) at dlerror.c:163
#20 0x00007f588be8cf82 in __dlopen (file=<optimized out>, mode=<optimized out>)
    at dlopen.c:87
#21 0x00007f589257fb9d in dtoa (rve=0x7f5800000000, sign=<optimized out>, decpt=
    0x7f588ec072a1 <ShowCustomDialog(GtkComboBox*, gpointer)+1056>, ndigits=-1884013950, mode=32600, dd=<optimized out>)
    at /home/debian/build/tor-browser/nsprpub/pr/src/misc/prdtoa.c:3215
#22 0x00007f589257fb9d in PR_dtoa (d=<optimized out>, mode=32600, ndigits=<optimized out>, decpt=0x7f588ec072a1 <ShowCustomDialog(GtkComboBox*, gpointer)+1056>, sign=<optimized out>, rve=0x7f5800000000, buf=0x7f5800000000 <error: Cannot access memory at address 0x7f5800000000>, bufsize=0)
    at /home/debian/build/tor-browser/nsprpub/pr/src/misc/prdtoa.c:3411
#23 0x0000000100000050 in  ()
#24 0x0000000000000000 in  ()

I'll contact the selfrando devs and meanwhile continue testing the patches without selfrando compiled in.

comment:10 in reply to:  9 Changed 21 months ago by cypherpunks

Replying to gk:
Add it to security.sandbox.content.syscall_whitelist and happy testing :)

comment:12 Changed 21 months ago by ah@…

mremap() was unconditionally re-enabled in Firefox 54 because wasm also needs it, so this is only a problem on Firefox 52:

comment:13 Changed 21 months ago by ah@…

I added a mremap() workaround to selfrando, release tb-v0.3.3 should fix these crashes.

comment:14 Changed 21 months ago by gk

Keywords: GeorgKoppen201709 added; GeorgKoppen201708 removed

Moving my tickets to the new month.

comment:15 Changed 21 months ago by gk

Keywords: TorBrowserTeam201709 added; TorBrowserTeam201708 removed

Items for September 2017.

comment:16 Changed 21 months ago by gk

Cc: boklm added
Keywords: TorBrowserTeam201709R added; TorBrowserTeam201709 removed
Status: newneeds_review

Okay, I've been running a build with the non-optional sandbox related patches and an updated selfrando for the last couple of days without any issues. Nice work, jld! I am confident that this is ready for the next alpha at least. bug_22692_v3 ( has the patches (8 to be exact) applied to tor-browser and the attached patch fixes the tor-browser-build part.

Last edited 21 months ago by gk (previous) (diff)

comment:17 Changed 21 months ago by boklm

The tor-browser-build patch looks good to me.

comment:18 Changed 21 months ago by jld

You might run into problems related to on Fedora, but the patch ( is simple and should backport, although I haven't tried.

Also, you may want to pick up, which fixes CVE-2017-7794.

comment:19 Changed 21 months ago by gk

Thanks, I updated bug_22692_v3 with the two patches (they applied cleanly) and will do a rebuild and further test while waiting on review.

comment:20 in reply to:  19 Changed 20 months ago by mcs

Replying to gk:

Thanks, I updated bug_22692_v3 with the two patches (they applied cleanly) and will do a rebuild and further test while waiting on review.

r=brade, r=mcs
We verified that the correct set of patches was backported. We did not try building and running on Linux, but that can be done once we have alpha candidate builds.

comment:21 Changed 20 months ago by gk

Keywords: tbb-backport added
Resolution: fixed
Status: needs_reviewclosed

Thanks. I put all the relevant commits onto tor-browser-52.3.0esr-7.5-2:

commit bf2b5cefbaddca978d5c5eca3b54f0f0af5c8d32
commit e3693eef06cadfc24d50abe34ae1bedf0385c3f8
commit 45459c3c090384c1632ac5c2aa4323ed6df656ce
commit 9a694d0d0cda658157ec2f86e68db0e72b556e04
commit d63e9b803e99682fc561e60c81cbe7b793b7b70f
commit 8bf9587a88239cdac723a5b1c37ef46a90a49c21
commit 08e00435a6657b00a06f7650276944d9b36ee36d
commit 5b224c4272f4752dea577c92f41b2f651778e975
commit 722a1a652291a27657ed1a0b7eefd134519daa8f
commit 018cc6d1fd6751a21bb46aa1b9afc7ca96a42c8c

jld, thanks again for doing the work for us. If you could watch out for further sandbox related security fixes that would be neat.

This will be available in our upcoming alpha, Tor Browser 7.5a5.

comment:22 Changed 20 months ago by gk

FWIW: the necessary tor-browser-build fix landed as well meanwhile: commit 85537ff8b5a7294138ed57e44818512aaabb9d57 on master.

comment:23 Changed 20 months ago by gk

Keywords: tbb-backported added; tbb-backport removed

Backported for 7.0.7: on tor-browser-52.4.0esr-7.0-1

commit 99459c71ad61f1d7fb3995e616771a30516cf25b
commit a878b3789b8b338124ba79efb5abba5f9bc34455
commit 6f946f9a53add44040dde190498c39d14922ec6e
commit 724bcf6dc8132b87eaf397494d777a30f7cd8210
commit 458e18efb75ff80d270cc875ac7c200da705752c
commit f439d50e540ed21a474a2062d1b902931c042a3e
commit f114f92dda8c67e8f013cf01974b0e1f65c0d04e
commit fcf32e4bdade5686f7dd3ca503d45fbfc6d56d2d
commit 74a7688a81cb539e02431fff6dea8ee204b6ff80
commit b4d1d2223d7fed2bd88b06fa4e0f65936618d417

Note: See TracTickets for help on using tickets.