Discontinuing the hardened Tor Browser series

by gk | April 20, 2017

When we started with the hardened Tor Browser series 18 months ago, we had two main purposes in mind:

  • It should give users an even more secure Tor Browser, especially at higher security levels where JavaScript is partially or completely disabled.
  • It should help us to identify issues earlier, therefore allowing to develop and backport fixes to the Tor Browser alpha and stable series.

The hardened series was a non-stable series on purpose, aimed at experienced users. The reason for that was not only the heavy performance impact of the hardening and debugging features we deployed. Rather, the impact of mixing both in Tor Browser seemed to be not well understood either: for example, does compiling Tor Browser with Address Sanitizer really lead to a more secure browser, given that the sanitizer is mainly intended as a debugging tool? Moreover, just using the hardening options provided by the toolchain seemed to be an incomplete solution to the problem—a bandaid until we could provide a more complete approach to hardening.

Looking again at its purposes above, we think it is safe to say that the hardened series indeed helped us identifying issues early on: with it we found bugs both in Firefox and tor and they got resolved quickly.

The picture is not so clear with respect to the promised security benefits. Part of the problem is that "more secure" can mean a wide variety of things. Another part is that we did not measure if we were indeed adding a security benefit to Tor Browser with all the techniques we deployed. What we learned over the course of the past 18 months, however, is that enabling expensive hardening can aid in making Tor Browser crashes much more reliable.

But that's not the only thing we learned. It seems we underestimated the confusion among users caused by labeling the series as "hardened" while at the same time including features for debugging purposes as well. The resulting experimental character of this series made it hard for users to decide whether that's actually the Tor Browser they wanted to have or not.

Where does that leave us? We've decided to stop having a "hardened" browser series, and instead we'll provide separate tools for the two purposes that it aimed to solve:

Users that are currently on the hardened update channel will get an update to the most recent Tor Browser alpha with a note to use Sandboxed Tor Browser instead for enhanced security. While the Sandboxed Tor Browser is currently in an experimental state itself, we feel that it provides much better safeguards against exploitation than the features we shipped in the hardened series.

Having Sandboxed Tor Browser for hardening the browser experience allows us to do an even better job with finding problems earlier in our Tor Browser patches or code in Tor Browser generally: we can include more debugging aids into special debug builds. We plan to do so and get back to dedicated debug nightly builds when we switch to our reproducible builds manager (rbm), which is happening soon.

Finally, thanks to all users of the hardened Tor Browser series. We hope Sandboxed Tor Browser and the upcoming debug builds will provide an even better match to your needs. If not, please make sure to file a bug in our bug tracker and we'll look into it.

Comments

Please note that the comment area below has been archived.

April 20, 2017

Permalink

For me the main characteristic of the hardened series was that it included Selfrando, is there a plan to make it land in alpha?

It would have been in the 7.0a3 alpha if we had not found last minute issues with selfrando and the switch to ESR52. It is planned to have it in 7.0a4 for 64bit Linux.

April 20, 2017

Permalink

When will you remove debugging information (-g) from release versions?

Hm. We are building Tor Browser the same way as Mozilla does it seems or are you saying the Mozilla bundles are not built with -g? That said we are stripping all the symbols to provide separate debug archives for investigating crashes. So, what exactly is added and problematic in our case if we follow Mozilla in that regard?

April 21, 2017

In reply to gk

Permalink

Are you saying that building with and without -g gives you the same binaries because of stripping?

April 23, 2017

In reply to gk

Permalink

ac_add_options --disable-debug-symbols
is what you need.

April 20, 2017

Permalink

Will miss the hardened series.

Used it with firejail

And yes, Where is selfrando?

April 20, 2017

Permalink

Seconding the prior comment... Sandboxing is a good addition, but it is not a "better match to our needs". It does not replace the memory exploit defenses (Selfrando), it only hopes to contain the exploit, once it was allowed due to the weak memory defenses.
It's like treating the symptoms of a problem... Please consider dealing with the cause - include the defenses (Selfrando) in the Sandboxed version?

The idea is not to sacrifice selfrando (or whatever similar means come to mind) for sandboxing. Sandboxed Tor Browser is pretty much agnostic to whatever Tor Browser version it is used with (it lets you select on which channel you want to be at start-up). All in all we still think that the current sandboxing code for Linux makes it less likely that a user gets exploited compared to using the hardened version. Sure, we can make the result even better by shipping selfrando to alpha (and later stable) users and that is planned and currently worked on.

April 20, 2017

Permalink

I am currently using a Tor Browser that is sandboxed, but the sandbox is on the hardened channel. about:tor still shows that I have 7.0a2-hardened. Will I/have I obtained the update to 7.0a3 not hardened

Update on previous comment:
7.0a3 was published to the sandbox but it refused because it was considered a downgrade. Bugs anyone?

> Bugs anyone?

If the behavior on 0.0.6 is anything but "detect that a hardened bundle is present, force a reinstall", then that's a bug.

If the sandbox code is anything older than that, I assume stuff breaks, because the sandbox handles updates somewhat differently from Tor Browser, and the code doesn't ever really expect channels to go away.

April 21, 2017

Permalink

Even after a clean install, the Sandboxed TB's Preferences don't look normal. All the checkboxes look empty, and stay empty after clicking on them. So, after a while it's hard to know what options are in the "checked state" and what aren't. Decided to reinstall and then left the checkboxes alone.
Funny - hope they are selected right. :-)

That's a new one for me, and I haven't seen that on any of the systems I've tested the code on. Though I'm not surprised that the UI can randomly break, especially considering I'm not really a UI programmer.

`sandboxed-tor-browser` follows the XDG Base Directory Specification, and writes a JSON format config file to a standard location (`$XDG_CONFIG_DIR/sandboxed-tor-browser/sandboxed-tor-browser.json`), so it should be easy to check what's actually set.

nb: While human readable, any/all bugs relating to "I edited it and it broke" will be ignored.

April 21, 2017

Permalink

- No sound at all - after the switch from hardenen TB to the latest standardTB,

So maybe you should warn users about this and not do the upgrade that was pushed today , if sound is very important to them,

warn in the popup that the users will lose all kind of sound in Linux, in all kind of dists that uses ALSA / jack instead of pulse-audio. It does not seems possible to fix this in Firefox now for us users :- ( should we go back to the 51-series?

what is your plan to re-enable sound on the web for TB in the future? (pulse audio can not be used for many reasons, security might also be one of them)

This is the only clue an user gets when an audio stream or html5-media with sound tries to start, a popup that says..:
https://support.mozilla.org/1/firefox/52.1.0/Linux/en-US/fix-common-aud…

Thank you for you work with TB and firefox

April 21, 2017

In reply to yawning

Permalink

is it really a big problem to support that?
Alsa seems to be in the kernel, and also pulse audio
seems to be just an extra risk-layer on top on Alsa (?)

I can understand that it is preferred to use only one
method, if it is true that no one cares
but pulse audio seems to me like a potential big risk and not worth it.

+adding a lot of junk to many the slim distros.. to do the same job

April 21, 2017

Permalink

Maybe it would have been better to wait until selfrando and sandboxing are stable and available before discontinuing the hardened builds? The current alpha version is almost unusable (downloading a file crashes the browser).

The version(s) of SelfRando that shipped with the `hardened` code had some "interesting" defects. The newer code is supposed to be better.

FWIW, sandboxing is version agnostic and works with the release bundle. While each person's experience will vary, it works well for my use cases, and has been all I use since the moment it started compiling. That said, I am biased, and it does break certain things, YMMV.

April 21, 2017

In reply to yawning

Permalink

Too bad I only have a x86 processor and no one that can run 64bits systems, will never have the opportunity to use the sandbox :/

April 22, 2017

In reply to yawning

Permalink

Anonymous wants 32-bit sandbox, and you're joking at him :)

April 21, 2017

Permalink

Rather random thought: f I am to use a stable intergrated sandboxed Tor browser in the future, is there a reason to use firejail on top of it?

"sandboxed" may mean different things here. Firefox 52 which Tor Browser 7.0 will be based upon ships with content sandboxing which should make it harder to exploit vulnerabilities found in the browser. Then there is Sandboxed Tor Browser for Linux 64bit users that is using bubblewrap to provide a process-wider sandbox. In it you can run any Tor Browser series, be it the stable one, the alpha one or some nightly build.

So, I assume you mean "content sandboxing" when talking about "sandboxed". In that case I'd say there are good reasons to use process-wide sandboxing in combination with it. We'd recommend Sandboxed Tor Browser for that, though.

There's design reasons why `sandboxed-tor-browser` is a separate executable. I don't see "integration" happening without a considerable amount of redesign in how Tor Browser works.

I personally think it's pointless to combine the bubblewrap based sandbox (`sandboxed-tor-browser`) with firejail, assuming that sort of configuration even works (and I suspect it won't), because of the amount of overlap between the feature sets.

April 21, 2017

Permalink

As a journalist in my country, I feel the security tor provides is necessary. But I'm far from an advanced tor user or developer. Should I be using the hardened alpha over the standard browser? "Alpha" is intimidating and sounds highly unstable. What should I do?

What is your system? If you're using Linux 64 you should be using the sandbox which provides much more security.

You shouldn't be using the (now) discontinue "hardened alpha" since it is more designed for people who want to debug and find bugs.

April 21, 2017

Permalink

problem with recent tor browser for windows........seems kind of defunt. doesn't really work taht stable and fails to load website....something wrong?

April 22, 2017

Permalink

Was the discontinuation of the experimental hardened browser completely at your discretion, or were you approached by any government entities that may have taken issue?

April 22, 2017

Permalink

"Alpha" is intimidating and sounds highly unstable. What should I do?"
You shouldn't use alpha.
(This easy answer was so many times misunderstood, because "hardened" looked like a better product without stable version. Thanks for removing it.)

April 23, 2017

Permalink

I am pleased that some clarity will come to the different versions as many that use TOR are not familiar with some of the geeky terms such as "Sandboxing". It has always been a problem that certain aspects of using TOR at maximum safely has been obscure on this group itself and one has had to go to other sites to find out what tweaks can be done to improve security. For example, i see on the latest version we still have all these links to google in the about:config page. Would there not be a way to delete anything to do with google perhaps in the security settings?

Thanks for your work

Oh, thanks. It seems we don't use jemalloc on Windows as we are building with mingw-w64. Might be worth thinking about whether we should.

Yes, but what breaks is enabling jemalloc when using mingw-w64 to cross-compile Tor Browser. I guess using it to build on Windows is working. But I have not tested that.

May 04, 2017

In reply to gk

Permalink

"Memory used by the system allocator that is currently allocated to the "
"application. This is distinct from the jemalloc heap that Firefox uses for "
"most or all of its heap allocations. Ideally this number is zero, but "
"on some platforms we cannot force every heap allocation through jemalloc.");

May 12, 2017

In reply to gk

Permalink

I hope you do not. Jemalloc is quite insecure (though at least it doesn't use deprecated APIs like sbrk like ptmalloc does...), whereas the native windows memory allocator is exceptionally well hardened, beyond the native malloc in glibc (ptmalloc and dlmalloc), or even the openbsd libc. Really the only downside it has is the Fault Tolerant Heap, and even that is not a big issue for a browser. The fact that jemalloc is not used on Windows makes Firefox significantly more hardened on that platform.

I didn't know that vanilla Firefox used --enable-jemalloc on Windows, though. I was under the impression that, like Tor Browser, it used the system malloc on Windows systems. I'll add that to my notes of security advantages Tor Browser has over regular Firefox for those who are under the impression that it is just Firefox + Tor!

Using jemalloc for Tor would be silly. Not only is jemalloc one of the least secure allocators due to large, aligned 2 MiB heaps, but it really is only useful for improving performance on highly multithreaded programs, like database servers and multithreaded browsers. Tor, which is rather infamously limited by its single work thread, would not benefit in the least from jemalloc.

Go and use copperhead bionic malloc or openbsd malloc and then we're talking. :P

April 27, 2017

Permalink

I'm concerned that only one person is working on sandboxed-tor-browser. How can I help without being a coder? Can I make donations directly to the sandboxed-tor-browser to the developer to help?

From what I've heard, this single person's funding for this project has also run out, so they are also no longer going to work on it full time. I'm not sure if this means it will go into maintenance hell, or if it'll be picked up by other people. I think you should go ask on #tor-project on OFTC about directly donating to that project.

It gets bug fixes. I'm not really doing new feature development or gigantic improvements, and the code is basically at the point where security improvements will require patching firefox, and usability improvements require fighting with D-Bus and doing UI code.

I'm also not in a position to be able to accept individual donations.