Tor Browser 5.5a4-hardened is released

by gk | November 5, 2015

We are pleased to announce the first release in our new hardened Tor Browser series. The download can be found in the 5.5a4-hardened distribution directory and on the download page for hardened builds.

For now this is for Linux 64bit systems only but we are thinking about supporting OS X and Windows in the future as well. As always, these builds are fully bit-for-bit reproducible.

The hardened series is built on top of the regular alpha series: it contains all the changes of the latter and further hardening, mainly against exploitation of memory corruption bugs. To this end Tor and Firefox are compiled with Address Sanitizer enabled (Tor even ships with another checker, the Undefined Behavior Sanitizer).

This additional hardening helps in two ways:

  • It gives users an even more secure Tor Browser (especially at higher security levels where Javascript is partially or completely disabled).
  • It helps identifying issues earlier allowing us to develop and backport fixes to the regular alpha and stable series.

This hardening comes with some downsides: these builds are slower than regular builds, and consume more memory. And, above all, they are considerably larger than alpha or release builds. That's why we decided to make another big change for this new series: there will only be one bundle shipped supporting all the languages found in alpha builds. Tor Launcher should help selecting the desired locale during the first start taking the operating system locale into account.

We should also point out that the hardening provided by Address Sanitizer is not perfect. In particular, if an adversary is able to determine that Address Sanitizer is in use, they may be able to use JavaScript to take advantage of this information and retain their ability to still exploit some classes of bugs. We are especially interested to learn if there are any clear ways to fingerprint our Address Sanitizer builds with a high degree of certainty for this reason. (Fair warning: performance-only fingerprinting may not be convincing without a lot of rigorous analysis, especially given that variables such as the JIT being enabled or disabled on many different types of hardware need to be taken into account).

Our initial hope was to use SoftBounds+CETS (or SafeCode), which do not have the weaknesses of Address Sanitizer, but these projects are not mature enough to compile Tor Browser (or Firefox, for that matter). We are actively exploring other hardening options, as well, and are happy to hear more suggestions.

We're especially eager to hear reports and stack traces from any crashes experienced in these builds, as they may be evidence of potentially exploitable memory issues that have not been detected in our normal builds! Advanced users may find these GDB instructions useful for this, but even the plain Address Sanitizer crash output should still be helpful.

Comments

Please note that the comment area below has been archived.

November 05, 2015

Permalink

Thanks! And reproducible builds are what we all need... for many of us to start reproducing ourselves! :)

For a few hours my *stable* torbrowser-launcher[1] learns about this *alpha* update available and give me no other choice than attempting (and failing, see below) to upgrade. To my understanding this is an error by itself, no alpha should be pushed to stable users by default, right?

FWIW, running directly the "start-tor-browser" command[2] instead of the torbrowser-launcher or its menu shortcut(s), *does* still launch stable 5.0.4 as expected and it just works as usual, thanks.

But GUI wonderland users might be in trouble, since I found no "user way" to still launch the stable version already installed (in such a setup, the above "start-tor-browser" command would be "hard to find" for most). Desktop menu shortcuts (torbrowser-launcher) always performs the update check, finds the alpha, declares the stable version "out of date", fails the update and then, it just exits.

The "Check for update next launch" option, as available in the settings GUI (desktop menu pointing to "torbrowser-launcher --settings") does not seem to have any effect either: checked or unchecked, it still attempts to proceed with the update, fails and give up.

Out of curiosity I also tried to upgrade from half a dozen random mirrors (still from the settings GUI, using the drop-down menu list), or by forcing LANG=C on the command line, but all I had were a range of errors[3] from 404 on the archive, or the signature file, to OpenSSL, eventually asking me to double check network connectivity or plain suggesting I might "be under attack".

Any troubles on your side, or is it "only me"?

<3

[1] 5.0.4 from torbrowser-launcher 0.2.0-1~bpo8+1 (jessie-backports), amd64
[2] .local/share/torbrowser/tbb/x86_64/tor-browser_es-ES/Browser/start-tor-browser
[3] http://pastebin.com/raw.php?i=wPg7TQG2

> Thanks! And reproducible builds are what we all need... for many of us to start reproducing ourselves! :)

There's still the problem of there not being any signed source tarballs in sight...

Shallow cloning takes >1GB (wtf?) and for whatever reason reliably fails for me.

November 05, 2015

Permalink

Please discard my previous comment cf. torbrowser-launcher, and accept my apologize for being that much out of place here. I should have figured it all better and faster. Code is truth! :)

And torbrowser-launcher is receiving some love it much needed.

Thanks && <3

https://github.com/micahflee/torbrowser-launcher/commit/de616b147dbe813…
https://lists.alioth.debian.org/pipermail/pkg-anonymity-tools/Week-of-M…
https://www.torproject.org/projects/torbrowser/design/#other-security
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804184

November 06, 2015

Permalink

This is great, hardened TBB is the way to go. I see a lot of potential as well as some interesting bug reports regarding this - hope priority is high to implement them!

November 06, 2015

Permalink

How do you collect the crashes + other data? Through user reports or some kind of telemetry?

November 06, 2015

In reply to gk

Permalink

If you do add it, hopefully it is disabled by default and can only be enabled by those who explicitly want to.

I don't think it's necessary to disable it by default; just asking before sending the crash report should be fine. It shouldn't be that much of an inconvenience to the end user to choose.

November 06, 2015

Permalink

We are especially interested to learn if there are any clear ways to fingerprint our Address Sanitizer builds with a high degree of certainty for this reason.

Well, if your plan is to enable that for all Tor Browser versions in the long run, then adversaries don't need to fingerprint: Just assume that Tor users run an Address Sanitizer build.

Assuming the hardened version can be ported to all platforms. Until then, hardening could split the anonymity set if it is fingerprintable.

CFI has many problems associated with it, both for security and performance. Honestly I would just wait for PaX's RAP to be public, and use that instead. Supposedly, RAP reliably kills the entire ROP class of exploits. The performance hit is around 4% for Chromium and the Linux kernel, so I presume it should be similar for Firefox as well.

RAP: RIP ROP
https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf

PaXTeam is going to release a post on the grsecurity furm explaining RAP in more detail soon, as the slides are a big vague.

Some brief info on CFI vs RAP
https://twitter.com/grsecurity/status/658280101411487744

An edit to my previous comment. Apparently RAP may not be made public in its full form, at least not for some time. Nothing is decided upon yet, but it seems PaXTeam may want to sell precompiled binaries using RAP, rather than selling or releasing the plugin itself, so Tor Browser may be out of luck here. Luckily, there are other CFI implementations which are not *too* bad, although none of them can protect the return address like RAP can. LLVM will soon support SafeStack upstream, which is a very low overhead CFI implementation using a second "safe" stack. If Tor Browser can be compiled with LLVM, then it likely can be compiled with SafeStack, which mitigates a large number of ROP exploits. If we really need return address protection, we may just have to wait and hope that RAP is released as open source.

November 06, 2015

Permalink

Runs very well on the latest Debian. I'll use this from now on.
Thanks for all the work you all do on this, very exciting.

November 06, 2015

Permalink

Since today, recaptcha from google don't work with tor from me, it reload indefinitly after checked ""im not a robot " maybe google use the captcha service to block people using tor to browse the web.

November 07, 2015

Permalink

> This hardening comes with some downsides: these builds are slower than regular builds, and consume more memory. And, above all, they are considerably larger than alpha or release builds. That's why we decided to make another big change for this new series: there will only be one bundle shipped supporting all the languages found in alpha builds.

In what way is the hardened version slower? As far as I can tell, the limiting factor for users is network latency and throughput.

Wouldn't having language-specific releases make each release smaller due to discarding the extra language support files?

Thank you for this new option! I know it's important for some people.

1) The whole browser runs slower (rendering, JS processing etc.).
2) No. The language packs we ship make up max 5 MB additionally while we have at least 100 MB for every language we ship separately.

November 07, 2015

Permalink

I am experiencing an inability to start TorBrowser after running 5.04 the first time after installation, closing it and then opening it. The result is a consistent appcrash. If I delete ..\TorBrowser and reinstall, TorBrowser will start and function. However, if I close and open, I get the apprash message.

Any help?

November 09, 2015

In reply to gk

Permalink

Hi gk. The problem is every time I try and launch the browser, it keeps trying to download the update and since it can't get the update, the browser closes.

I guess you're using torbrowser-launcher package? The 404 occurs because this alpha release is shipped as unique archive including all languages, while torbrowser-launcher is trying to download the usual per-language archive. The 404 error is actually a good thing, since the upgrade attempt is an error (stable vs. alpha releases). Please see the first two comments of the thread.

November 07, 2015

Permalink

Hardened builds sound great! Thank guys.

Now, will the "hardened" builds graduate to stable releases? Or will it be an alpha-only variant?

I would really like to start using the hardened builds but on the stable series.

November 09, 2015

Permalink

Will you guys be including AppArmor/SELinux profiles for both normal and hardened versions in the future?

The hardened will likely have the exact same exact policy as the non-hardened version, since the only changes involve memory handling, not filesystem access.

I'd like to second this question/request though. Ideally, other MAC policies will also be included, since it should be easy to port AppArmor to grsec RBAC, RSBAC, TOMOYO, SMACK, etc.

Also to arma or any of the other Tor devs, is there any chance of including a seccomp patch or wrapper for Tor Browser? It would *massively* improve security. It wouldn't need to be a patch, it could also be an executable wrapper, as seccomp policies are propagated across execve() and related calls. If there is a decision to add a seccomp policy to Tor Browser, I would gladly help.

November 12, 2015

Permalink

Please give me an address to upload one of my personal hardened Torbrowser variation versions to your project as a form of an illustrative, hopefully useful feedback for development. It'll contain specific Noscript settings, About:config changes, Internal app changes, lay-out changes and some little more useful OS independent stuff.

November 16, 2015

Permalink

AS - aware Tor

There are some clients like LASTor & Astoria that claimed to be AS-aware

will it be implemented in original tor????

November 20, 2015

Permalink

how can i block all installed CA and enable only needed? i am not not going to click everything on the web so i don't need all this CAs. thanks

November 22, 2015

Permalink

I'm quite a noob. I want to run a hidden service. Can I use this over the stable one? And are there any instructions to do so?

November 24, 2015

Permalink

Are there any plans for releasing a hardened Tails as well? I would really love to see and use a distribution that uses ASAN all over.

As far as I know are the Tails folks interested in this. One of the blockers, though, is that Tails is not available for 64bit systems and we don't plan to ship 32bit ASan enabled Tor Browsers.

December 11, 2015

Permalink

Hi, to summarize what I understand from article and comments:

1. Tor Hardened Bundle is just making memory use more secure so browser may not be exploited for bugs.

2. Everything else is same as regular TBB.

3. Address Sanitizer has to do compilation/running of scripts.

Please correct me. Thanks!

December 24, 2015

Permalink

hi thanks for the hardened releases they are great
can you still mantain the one used briefly by whonix? now it cannot be used since is 64bit only.

thank you, you should cooperate with whonix team, hardened tor browser there was jummy.
:)

January 26, 2016

Permalink

The adversary can somehow detect that the application is using the ASan allocator, which is quite different from the system malloc. The ideas below are just speculations, but studying the allocator source carefully may help to develop a fingerprinting method.
Leaking a single heap address will reveal that the heap resides at a predefined part of the address space.
The size class buckets in ASan may differ from those in glibc - if the adversary has fine-grained control over malloc sizes he can probably detect which size ranges belong to which size classes.
Also, allocation and deallocation of the same object in a loop is done at almost no cost with glibc allocator, but will cause heap growth with ASan because of the quarantine. After having reached a certain upper bound the growth will stop, and the time spent in malloc() will stabilize.
Doing many allocations in multiple threads will result in contention on the global quarantine, which can possibly be measured.

Alexander Potapenko