tbb-hardened

Discontinuing the hardened Tor Browser series

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.

Tor Browser 5.5a5-hardened is released

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

This release features important security updates to Firefox.

Additionally, we included updated versions for Tor (0.2.7.6), OpenSSL (1.0.1q) and NoScript (2.7). Moreover, we fixed an annoying bug in our circuit display (circuits weren't visible sometimes), isolated SharedWorkers to the first-party domain and improved our font fingerprinting defense.

On the usability side we improved the about:tor experience and started to use the bundled changelog to display new features and bug fixes after an update (instead of loading the blog post into a new tab). We'd love to hear feedback about both.

On the hardening side we are compiling Firefox with -fwrapv now. This is mitigating possible issues with some types of undefined behavior in Mozilla's code.

Tor Browser 5.5a5-hardened comes with a banner supporting our donations campaign. The banner is visible on the about:tor page and features either Roger Dingledine, Laura Poitras or Cory Doctorow which is chosen randomly.

Note: There are no incremental updates from 5.5a4-hardened available this time due to a bug we detected while building. The internal updater should work, though, doing a complete update.

Here is the complete changelog since 5.5a4-hardened:

  • Update Firefox to 38.5.0esr
  • Update Tor to 0.2.7.6
  • Update OpenSSL to 1.0.1q
  • Update NoScript to 2.7
  • Update Torbutton to 1.9.4.2
    • Bug 16940: After update, load local change notes
    • Bug 16990: Avoid matching '250 ' to the end of node name
    • Bug 17565: Tor fundraising campaign donation banner
    • Bug 17770: Fix alignments on donation banner
    • Bug 17792: Include donation banner in some non en-US Tor Browsers
    • Bug 17108: Polish about:tor appearance
    • Bug 17568: Clean up tor-control-port.js
    • Translation updates
  • Update Tor Launcher to 0.2.8.1
    • Bug 17344: Enumerate available language packs for language prompt
    • Code clean-up
    • Translation updates
  • Bug 12516: Compile Tor Browser with -fwrapv
  • Bug 9659: Avoid loop due to optimistic data SOCKS code (fix of #3875)
  • Bug 15564: Isolate SharedWorkers by first-party domain
  • Bug 16940: After update, load local change notes
  • Bug 17759: Apply whitelist to local fonts in @font-face (fix of #13313)
  • Bug 17747: Add ndnop3 as new default obfs4 bridge
  • Bug 17009: Shift and Alt keys leak physical keyboard layout (fix of #15646)
  • Bug 17369: Disable RC4 fallback
  • Bug 17442: Remove custom updater certificate pinning
  • Bug 16863: Avoid confusing error when loop.enabled is false
  • Bug 17502: Add a preference for hiding "Open with" on download dialog
  • Bug 17446: Prevent canvas extraction by third parties (fixup of #6253)
  • Bug 16441: Suppress "Reset Tor Browser" prompt

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.

Syndicate content Syndicate content