Tor Browser 5.5a4-hardened is released

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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

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"?


[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

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

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

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!

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

Currently only through user reports but I actually like the idea of having a mechanism like Firefox's crash reporter to help us here in the long run.

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.

Thirded. At the very least, warn users via GUI more visibly than FF does.

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.

People can use Tor with third party applications.

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

>We are actively exploring other hardening options, as well, and are happy to hear more suggestions.

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.


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

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.

>a large number of ROP exploits
How about eliminate ALL ofthem COMPLETELY, as the cited work promises?

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.

Something I noticed is that it doesn't show the circuit path. Is this intentional?

No. I think this is which we finally tracked down. It will be fixed in the next release.

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.

Google is not your friend ; disconnect/startpage/ixquick/googleencrypted are better options.
new identity or new tor circuit could also help you.

*i hate stackexchange (and wikipedia) for their famous mediocrity.but, for a quick and easy answer, follow the link.

So what's the solution when a non-google page includes a google-based recaptcha?

yes , they trick us because we trick Nsa

Try not to use go ogle SPY's lol

Revolutionary Quantum Encryption Coming!

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

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?

The exact error message would maybe help + operating system and version (and you mean 5.0.4 and not 5.5a4-hardened, right?).

I'm currently getting a 404 not found error when trying to download the update.

There is no update for the hardened release available yet. This is the first release in the new series.

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.

i know this is sort of off topic but is there any love with onionshare and tor ?

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.

For now it will only be an alpha-only variant. We have no plans to include it into the stable series (yet).

Even the normal builds have significant hardening.

flash player installe bat facebook video not sapot

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.

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.

Open a ticket with info/attachments here:

Flash doesn't seem to be detected.

AS - aware Tor

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

will it be implemented in original tor????

for Linux users: libpng is vulnerable!

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

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?

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.

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!

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.

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

Great work.
For more hardening options you may want to look at and

Syndicate content Syndicate content