Tor Browser 6.5a6 is released
This release features important security updates to Firefox. Other components got an update as well: Tor to 0.2.9.6-rc and HTTPS-Everywhere to 5.2.8.
With this release we made progress in both the usability and security area. In the former we fixed the broken preferences pane in non-en-US bundles and moved to pt-BR bundles for Portuguese as it turns out that all our translations for Portuguese are containing Brazilian language strings. We added links to the Tor Browser Manual, an effort led by the community team to make help easier available for our users in case of problems.
On the security side we are proud to announce the first fruits of our sandboxing efforts.
On Linux the Tor Browser sandbox is centered around Linux namespaces along with seccomp-bpf, and attempts to reduce the attack surface available to adversaries to prevent exploits from succeeding, and to limit the capabilities of an attacker in the event that they do manage to compromise either the tor client instance or the browser itself. This is done by creating lightweight namespace based containers in which the Tor Browser components are run, with various restrictions imposed by the operating system. For example, the container that the browser runs in does not have an IP address to leak, or a connection to the external network except via Tor.
It is made available to end users as a separate downloadable binary,
sandboxed-tor-browser, that manages installing and updating Tor Browser, configuring Tor and the sandbox, and running the actual sandboxed Tor Browser. Having
bubblewrap installed is required for this to work. Additional documentation about the implementation, known issues, and frequently asked questions is available at our wiki.
We have also made some progress with sandboxing on macOS. Building on the work done in the past by IronFox and similar projects, we have created sandbox profiles for the Tor daemon and for Tor Browser itself. These profiles, along with some command line scripts that use Apple's sandbox-exec command to start Tor and Tor Browser, are included in our Tor Browser 6.5a6 OSX packages. At this time we are asking advanced users to use the OSX sandbox profiles on an experimental basis and give us feedback on any problems that they encounter. In the future, we hope to create software for macOS that is similar to the Linux Tor Browser sandbox.
Besides work on sandboxing this release features our first step in exploring options to harden the memory allocator. We have enabled jemalloc4 on Linux bundles and abort on redzone corruption. We are here especially interested in performance and stability related feedback.
Here is the full changelog since 6.5a5:
- All Platforms
- Update Firefox to 45.6.0esr
- Update Tor to tor-0.2.9.6-rc
- Update Torbutton to 220.127.116.11
- Bug 16622: Timezone spoofing moved to tor-browser.git
- Bug 20701: Allow the directory listing stylesheet in the content policy
- Bug 20556: Use pt-BR strings from now on
- Bug 20614: Add links to Tor Browser User Manual
- Bug 20414: Fix non-rendering arrow on OS X
- Bug 20728: Fix bad preferences.xul dimensions
- Bug 20318: Remove helpdesk link from about:tor
- Bug 20753: Remove obsolete StartPage locale strings
- Translation updates
- Update HTTPS-Everywhere to 5.2.8
- Bug 16622: Spoof timezone with Firefox patch
- Bug 20707: Fix broken preferences tab in non-en-US alpha bundles
- Bug 20709: Fix wrong update URL in alpha bundles
- Bug 20556: Start using pt-BR instead of pt-PT for Portuguese
- Bug 20809: Use non-/html search engine URL for DuckDuckGo search plugins
- Bug 20837: Activate iat-mode for certain obfs4 bridges
- Bug 20838: Uncomment NX01 default obfs4 bridge
- Bug 20840: Rotate ports a third time for default obfs4 bridges
- OS X
- Bug 20121: Create Seatbelt profile(s) for Tor Browser
Only if you download it explicitly. It's very experimental though (version 0.0.2), and has some limitations like lacking X11 isolation (this can be mitigated by using Xephyr correctly), and being based on bubblewrap, which requires either setuid or unprivileged user namespaces in order to set up mount namespaces. But it's certainly a huge improvement over the current state of things.
To clarify a bit.
The X11 isolation thing is hard to solve for the general case, because I wanted to keep the required dependencies to a minimum, Tor Browser does not react well to "there is no window manager", and unless people use Xpra, the user experience is a bit jarring. It does work fine with most of the popular options for such things, there's just more work involved. X11 scares me, so I'd like to figure out a good way to improve this.
Requiring setuid or unpriviledged user namespaces is a general Linux limitation, centered around a lot of the useful unshare() flags requiring CAP_SYS_ADMIN. I made the design choice to rely on a third party component in lieu of part of the install instructions reading "You may need to make one of the binaries SUID root depending on your system configuration". I will likely revisit this when CONFIG_USER_NS is both ubiquitous and not utterly terrifying, but I don't foresee that happening in the near term future.
Not OP. I have to admit, while I understand the basic idea, the whole X11 isolation thing is a bit over my head. What does all this mean for Wayland/Mir (which uses DRM, device files in /dev/dri and some shm stuff I think). This might necessarily expose the video card's DRM driver, but I suppose there are many different trade-offs to be considered.
I have a feeling supporting it might be easier than X11 because the Wayland protocol is simpler and does not have hundreds of extensions, but I can't say with any amount of certainty. Wayland is also sometimes considered to be more secure than X11 in principle, due to its simpler design. Is sandbox support on Wayland something you've planned or thought about? And does the sandbox work under Wayland+Xwayland?
> What does all this mean for Wayland/Mir (which uses DRM, device files in /dev/dri and some shm stuff I think). This might necessarily expose the video card's DRM driver, but I suppose there are many different trade-offs to be considered.
Don't know about Mir, since I haven't looked at it at all. Wayland strictly speaking (and in the model that I envision this) will not need a /dev/dri in the container to function (access to the video card hardware will be via the compositor).
> I have a feeling supporting it might be easier than X11 because the Wayland protocol is simpler and does not have hundreds of extensions, but I can't say with any amount of certainty.
Supporting X wasn't that hard either. The mountain of extensions triggered a few interesting bugs in Firefox and cairo, but that's because they didn't behave correctly when common extensions were non-functional.
> Wayland is also sometimes considered to be more secure than X11 in principle, due to its simpler design. Is sandbox support on Wayland something you've planned or thought about?
Yes. When firefox supports native Wayland, the sandbox will be updated to utilize that.
> And does the sandbox work under Wayland+Xwayland?
Yes. One of the test systems was Fedora 25.
> Wayland strictly speaking (and in the model that I envision this) will not need a /dev/dri in the container to function (access to the video card hardware will be via the compositor).
I thought libdrm in an app could open the device nodes directly for 3D rendering, but I guess I was thinking of the compositor. The graphics stack is definitely not my fortè.
Thanks for the answers. I'm glad to hear the sandbox will support Wayland when Firefox does (I guess we're waiting on Firefox to support GTK3?), and that Xwayland works in the meantime. And thank you for all your hard work in keeping Tor Browser safe!