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.

khled.8@hotmai.com

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!

khled.8@hotmai.com

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

khled.8@hotmai.com

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