Tor Browser 6.5a6 is released

by gk | December 13, 2016

Tor Browser 6.5a6 is now available from the Tor Browser Project page and also from our distribution directory.

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 1.9.6.8
      • 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
  • Linux
    • Bug 20352: Integrate sandboxed-tor-browser into our Gitian build
    • Bug 20758: Make Linux sandbox build deterministic
    • Bug 10281: Use jemalloc4 and abort on redzone corruption

Comments

Please note that the comment area below has been archived.

Anonymous (not verified) said:

December 14, 2016

Permalink

So if I get this correctly, this version has a sandbox for Linux as well as the Selfrando integration?

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.

Anonymous (not verified) said:

December 16, 2016

Permalink

> 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!

Anonymous (not verified) said:

December 14, 2016

Permalink

> On the security side we are proud to announce the first fruits of our sandboxing efforts.
yes but i suggest that the sandbox be coupled with a mac protection :
could you give us some precision and which mac you should choose and how to set up this one ?

If you're using RHEL, Fedora, or CentOS, you'd probably want to use SELinux. You won't have much option, because those distros don't give you much choice, and you can't stack multiple (LSM-based) MACs. If you're using Debian, Ubuntu, or Mint, you'd probably want to use AppArmor. If you're using a system with grsecurity like Hardened Gentoo, then you'll be able to use RBAC. I've heard that SMACK is a very easy to use label-based MAC, but I've never used it before.

Probably the easiest MAC to use is AppArmor. There is lots of documentation on how to write an AppArmor profile. I'm sure Tor Project would be willing to add a profile to their official downloads if someone wrote one. I've been considering it but I've been putting it off because I use RBAC, not AppArmor.

There a some Apparmor profiles like in Tails, Whonix and the probably the most appropriate one is included in Tor Browser Launcher (by Micah Lee, but I think it's not enforced by default)

https://github.com/micahflee/torbrowser-launcher/tree/master/apparmor

An issue might be that the apparmor profile from Micah Lee expects as directory for tbb something like /home/*/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/

Anonymous (not verified) said:

December 14, 2016

Permalink

This is really awesome that an officially sandboxed tbb has finally in apha and I can't wait for it to be stable. I have installed Firejail and it has worked seemly good for me except for it's Xpra sandboxing which is glitchy. I wonder if this will effectively replace firejail.

Anyways, thank you Tor project and particularly, Yawning Angel for all the efforts!!

Anonymous (not verified) said:

December 14, 2016

Permalink

Thanks for the great work on this! I am particularly excited about the sandbox; so far, I have run into two issues with it:

  • After the browser updates and it attempts to launch, it throws the error "Failing with error: runtime error: invalid memory address or nil pointer dereference" and takes me to the sandbox settings. This happens with both the stable and alpha releases; subsequent attempts to launch work fine and do not have this problem.
  • When running with the security slider is not set to High, the sandboxed browser crashes when viewing Wikipedia articles. I see "fatal error in the user interface: waitid: no child processes" in the log, but no other information. This happens in both stable and alpha, but the crash does not happen even after enabling JavaScript when running on High security.

Weird, which flavor of Linux (Platform, distribution, version number).

I've been using this as my main browser for a few months now and haven't seen either issue, but, there's a lot of things that happen under the hood that can break in unexpected ways.

Anonymous (not verified) said:

December 14, 2016

Permalink

Arch Linux on x86_64, latest packages. I spent some additional time debugging the crash and it seems to be related to ffmpeg; if I disable the extra codecs, it goes away. I'm guessing ffmpeg is trying to make a syscall that isn't allowed by the sandbox. If I get some more time, I will build a kernel with CONFIG_AUDIT and see if I can find out more.

Alternatively if you have a kernel that allows unprivileged user namespaces (which is not the default in Arch, for good reason), you can strace the sandbox process, and figure things out that way.

The seccomp stuff isn't setup to kill the process, just ENOSYS non-whitelisted calls...

Edit: `sudo -E strace -ff -o /tmp/ff.trace -u $USER ./sandboxed-tor-browser` makes me think that this isn't seccomp related because the only calls that are being rejected are a few to `quotactl()` (harmless). I'll look into it a bit more and post my findings on the ticket.

yawning

yawning said:

December 14, 2016

Permalink

Just to bring some closure to this, I believe this is fixed in master.

To prevent sandboxed processes from consuming resources, `sandboxed-tor-browser` imposes caps on resource consumption via `rlimit()`. Something about the JS, with the slider on low, specific to wikipedia was causing the stack to grow over the limit.

I was probably overly aggressive when setting the limit so it is now something that more resembles a typical desktop system.

CONFIG_AUDIT would only provide information if syscalls were configured with SECCOMP_RET_TRAP. Using SECCOMP_RET_KILL would not result in any messages from the audit subsystem, nor would SECCOMP_RET_ACTION (which is what Yawning's sandbox does, unless you configure auditd to explicitly log ENOSYS).

Anonymous (not verified) said:

December 14, 2016

Permalink

Cannot start the sandboxed version on macOS :

b0x:Sandboxed Tor Browser admin$ dyld: Library not loaded: /usr/lib/libstdc++.6.dylib
Referenced from: /Users/admin/Downloads/Sandboxed Tor Browser/TorBrowser.app/./Contents/MacOS/firefox
Reason: no suitable image found. Did find:
file system sandbox blocked open() of '/usr/lib/libstdc++.6.dylib'
file system sandbox blocked open() of '/usr/lib/libstdc++.6.dylib'
./start-browser-with-sandbox: line 24: 1797 Abort trap: 6 sandbox-exec -f "$SB_PROFILE" -D "HOME_DIR=$HOME" -D "CURRENT_DIR=$BASEDIR" -D "TORBROWSER_APP_DIR=$TORBROWSER_APP_DIR" -D "TORBROWSER_DATA_DIR=$TORBROWSER_DATA_DIR" "./Contents/MacOS/firefox"

[2]+ Exit 134 ./start-browser-with-sandbox

Apparently Apple changed something in the latest Sierra update. Try this:
1. edit tb.sb using a plain text editor
2. move the line that reads (subpath "/usr/lib") from the (allow file-read-metadata ... ) section to the (allow file-read* ...) section.
3. Try again.

Doing this fixed the problem for me.

Anonymous (not verified) said:

December 15, 2016

Permalink

Thanks mcs!
This fixed the browser start issue, however it still cannot connect to the tor daemon correctly, this is the log:

b0x:Sandboxed Tor Browser admin$ ./start-browser-with-sandbox &
[2] 6065
Thunder:Sandboxed Tor Browser admin$ [warn] kq_init: detected broken kqueue; not using.: Undefined error: 0
2016-12-15 19:25:50.288 firefox[6070:278989] kCFURLVolumeIsAutomountedKey missing for file://localhost/Volumes/Tor%20Browser/: The file “Tor Browser” couldn’t be opened because you don’t have permission to view it.
1481822750600 addons.xpi-utils ERROR Unable to read anything useful from the database
0 migrated.
Dec 15 19:25:52.000 [notice] New control connection opened.
Dec 15 19:25:52.000 [warn] Got authentication cookie with wrong length (0)
Dec 15 19:25:52.000 [notice] New control connection opened.
2016-12-15 17:25:54.748 firefox[6070:278987] unable to obtain configuration from file://localhost/Library/Preferences/com.apple.ViewBridge.plist due to Error Domain=NSCocoaErrorDomain Code=257 "The file “com.apple.ViewBridge.plist” couldn’t be opened because you don’t have permission to view it." UserInfo={NSFilePath=/Library/Preferences/com.apple.ViewBridge.plist, NSUnderlyingError=0x7f8f0e911220 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}
2016-12-15 17:25:54.754 firefox[6070:278987] IMKInputSession presentFunctionRowItemTextInputViewWithEndpoint:completionHandler: : *NO* NSRemoteViewController to client, NSError=Error Domain=NSCocoaErrorDomain Code=4097 "connection from pid 0" UserInfo={NSDebugDescription=connection from pid 0}, com.apple.inputmethod.EmojiFunctionRowItem

//

I wonder what is this file://localhost location...
This is the TorBrowser.app which came with this release, nothing else in the Sandboxed folder so it cannot be something I am doing wrong, I guess?

Anonymous (not verified) said:

December 14, 2016

Permalink

The FBI seems to target specifically windows users. Additionally, GNU/Linux users already have apparmor (whonix, torlauncher, tails etc contain apparmor profiles) and firefail (essentially seccomp + linux name places) and/ or selinux -- would it therefore not male sense to prioritize windows instead of the GNU operating system (esp cos there are more Win than GNU OS users)?

Windows is planned, though I'm not going to be the one developing it as far as I know.

As far as prioritization goes, I use Linux, I don't use Windows, and I wanted a sandbox so I wrote one.

Anonymous (not verified) said:

December 15, 2016

Permalink

Are people already working on win solution is it just "planned" (to begin)?

For me as a non-tech-savvy person, what you are doing seems to be a lot like what the firejail people are doing -- are there difference save that your solution is part of the tbb installation (what's great and probably means that more people are going to use it, esp cos people already trust the tor developer enough to install their binary and firejail adds another project to be trusted)?

> Are people already working on win solution is it just "planned" (to begin)?

Not sure.

> what you are doing seems to be a lot like what the firejail people are doing -- are there difference save that your solution is part of the tbb installation (what's great and probably means that more people are going to use it, esp cos people already trust the tor developer enough to install their binary and firejail adds another project to be trusted)?

Something similar might be possible with firejail and a bunch of shell scripts (and that's what I used to use before I wrote this). Handling things like the updater properly, limiting the control port's information/functionality access, filtering system calls based on argument (beyond a small handful), limiting shared library access, a nice friendly UI and etc would still require additional code.

Anonymous (not verified) said:

December 15, 2016

Permalink

i still get people asking me to solve window issues.. sorry i am linux too these days.. no matter how i explain why... sorry but the one finger solution is not available anymore.. even basic knowledge these day even more so now is important now to expand one knowledge (am always and still learning) .. linux is becoming more simpler to cross over from windows .. just do it .. with a bit of effort you will never return to closed source ie windows etc.. rant out

Windows has much more limited sandboxing abilities. Whereas Linux has seccomp to whitelist both syscalls and syscall arguments, Windows can only disable a class of syscalls (the System Call Disable Policy, which only works on Windows 8 and newer). There are two x86_64 syscall tables in Windows, the win32k table (containing ~1000 syscalls, see http://j00ru.vexillium.org/win32k_x64/) and the NT table (containing ~400 syscalls, see http://j00ru.vexillium.org/ntapi_64/). System Call Disable Policy disables the win32k syscall table. Unfortunately, that still leaves 400 syscalls, running entirely in ring 0, without any form of filtering. Compare that with Linux, which has one x86_64 syscall table, containing only a fraction of the number of syscalls (see http://man7.org/linux/man-pages/man2/syscalls.2.html, only about 300 of which are active on x86_64 platforms). With seccomp, you can reduce that to an arbitrarily low number, *and* filter the arguments of any syscall (although you can only filter the raw arguments in the registers, not any memory which an address in the register may point to).

Additionally, in Linux you can create namespaces, which give each process its own unique view of the system. With network namespaces, each process will see its own network interface. With mount namespaces, you can have a process see only the mountpoints you want, and hide others. With UTS namespaces, you can spoof the hostname of the system (so exploits which send your hostname to the feds, like the svg one we saw just recently, would be given a dummy value like "amnesia" or the kernel-default "(none)" rather than your real hostname).

Overall, although Microsoft has taken steps to improve its operating system's security, they really haven't given us many options to provide Tor Browser users with a solid sandbox. The best features they provide are only available to enterprise users who pay for the more expensive versions of Windows. While I'm sure there are ways to improve security on Windows beyond what we have now (and beyond easy things for users to do like installing EMET and using an unprivileged main account), the effort required would not give us a huge benefit. It's better to work on Linux and tell Windows users to switch over if they need actual security. Not that Linux is inherently more secure on its own, but Linux certainly provides a better infrastructure to secure applications and reduce attack surface area that Windows is utterly incapable of.

yawning

yawning said:

December 16, 2016

Permalink

This should be fixed in master, though my fix is a guess since I had to force the conditions that I assume were triggering the issues, and am not sure if that is the same as what other people were experiencing.

If someone with this issue can tell me the output of `ps xmsh | wc -l` at the time of the crash, then I'll have more confidence that I got it right.

Anonymous (not verified) said:

December 16, 2016

Permalink

Appears to be fixed in master. At least I can't reproduce it any longer.

$ ps xmsh | wc -l
760

Excellent, thanks.

The sandbox sets rlimits upon initializing the UI, and I was setting RLIMIT_NPROC to 512. Since it counts all threads/processes running under the real UID, if the user has a lot of things running, the UI would fail in interesting ways.

Sorry about that, I'll come up with a better solution for enforcing that limit when I have a moment to think about it (making the updater work better is higher on my priority list for now).

Anonymous (not verified) said:

December 16, 2016

Permalink

Could you, please, add an observer to detect programmatic change of resolution and warn about it (e.g. in Browser Console, at first)?

Anonymous (not verified) said:

December 16, 2016

Permalink

This Tor version and the prevous one also have NoScript problem combined with Facebook:

close tor browser then open
go to https://www.facebookcorewwwi.onion
Noscript - Forbid scripts globally, temporarily allow all this page
Now facebook will not stop loading.
Noscript - put it back to allow scripts globally
Facebook continues to nonstop reload, even though noscript has been returned to original setting.
Have to exit out of tor and start over

I have experienced huge memory leaks when visiting Facebook for a long time now. The only way to prevent this is to enable NoScript only for FB's "captcha" and then disabling it completely. Sometimes FB even freezes the whole operating system (I use GNU/Linux), so something is definitely wrong with either Tor Browser or Facebook.

The reason is that nobody investigated this thoroughly so far and has written a patch. If you want to do that, please go ahead, we won't have time for that anytime soon.