Pick a more accurate name for the "hardened" Tor Browser

I learned last week that the "hardened" Tor Browser is potentially more vulnerable to attack than the vanilla one -- since asan is at odds with some of the address randomization stuff that we would want in a true hardened build.

In particular, it sounds like the hardened version is intended to be used by developers and other people who are able to report bugs, since it will be more likely to crash and is hopefully better prepared to explain where the crash was.

Then I saw https://trac.torproject.org/projects/tor/ticket/20773#comment:4 today, where yawning's sandboxed tor browser has to open up some more surface area (specifically, /proc) for the hardened version to use asan correctly.

At the same time, we have users who are eager to use the hardened version, because of how crappy Firefox's security is, and they are frustrated with us that we will only make a hardened version of tor browser available for linux users.

Should we change its name to better reflect what it does and what it's for?

"debugging"? "fragile"? "developer"?

Who are your ideal users of this version, and are they using it?

added TorBrowserTeam201704 component::applications/tor browser owner::tbb-team priority::medium resolution::fixed severity::normal status::closed type::defect labels

(One could argue that selfrando is indeed hardening. And that's great. If we think it's good for users, let's put that into the alpha version and eventually into the mainline version.)

since asan is at odds with some of the address randomization stuff that we would want in a true hardened build.

Is this "it doesn't run on grsec kernels because of PaX", or is there more that you're referring to here.

(Since we're talking about the parts that are hardened, release/alpha do not build tor with seccomp support. This would be good to have in alpha, though it will introduce a library dependency.)

I know little here -- I'm just opening the ticket so the topic gets attention and a resolution.

Folks on irc were talking about how asan and (I assume it was) aslr are not easily compatible, and/or how asan provides more predictable addresses for rop-style gadgets.

I guess step zero here then is to find somebody who has a strong opinion about the topic and also is right? :)

Trac:
Parent: N/A to #20955 (moved)

Trac:
Parent: #20955 (moved) to N/A

Given that ASan is only a debugging tool, and the only hardening feature it actually provides against intentional attacks (protection from linear buffer overflows, all other techniques are mitigated by selfrando and soon, jemalloc4's redzones) is already provided by selfrando AFAIK, I agree with changing the name. I think calling it hardened is disingenuous at best, and turns users looking for extra security into unwitting guinea pigs at worst.

Arma is right that it increases the amount of ROP gadgets, although it doesn't affect ASLR. It's PaX which it's not compatible with, as well as some other hardening techniques, but I don't believe ASLR itself is directly affected. And of course, such an incredibly complex runtime adds surface area for attack which can be exploitable in some circumstances. In one instance, there was a bug in the entire runtime which caused the sanitizer to lead to a local root privesc when used to instrument setuid binaries. Of course, Firefox isn't setuid, so a similarly nasty vulnerability would "only" lead to regular code execution, not privesc, but that's still very bad.

Personally, I support changing the name to "debug build", considering it's all experimental and the security features that are good for users would be eventually mainlined as arma said, so the features there include instrumentation for finding bugs, even at the expense of security in production. I don't think "developer build" is a good name, because that's more what the alpha is for (testing new features, etc), whereas the debug build is for using features which help actively find new bugs. Chromium's alpha build is called developer for example (canary -> developer -> beta -> stable, IIRC).

Plus, there's the sandbox being developed, so it's not like people who were under the impression that they were getting an extra secure version of Firefox would suddenly be told they were using the wrong version the whole time. They'd have something to migrate to (which actually does supplement security, even if it's in its early development stages).

https://labs.riseup.net/code/issues/7155#note-9 has some useful information on ASan and its problems.

For those following along at home: We started the discussion about what to do on the tbb-dev list with: https://lists.torproject.org/pipermail/tbb-dev/2017-February/000454.html.

Trac:
Keywords: N/A deleted, TorBrowserTeam201702 added

Moving tickets to March

Trac:
Keywords: TorBrowserTeam201702 deleted, TorBrowserTeam201703 added

To move things forward and following our discussion on tbb-dev we decided to drop the hardened series as-is with the update next week. For users that looked for a hardened setup on Linux64 we'll point to the sandboxed-tor-browser. For those that want to help with debugging we make sure that we get a replacement into our new build tool, rbm, which we need to do anyway as we have some related deliverable for Tor Browser later this year.

Users will get updated to the alpha which will hopefully have selfrando included then (depends on getting #20683 (moved) fixed in time).

Trac:
Keywords: TorBrowserTeam201703 deleted, TorBrowserTeam201704 added

Users will get updated to the alpha which will hopefully have selfrando included then (depends on getting #20683 (moved) fixed in time).

How's this going to work? (In detail from the perspective of the updater.)

Or more to the point, is it still just "download an XML file, download + apply a MAR"? Where's the channel change notification? If possible I'd like to mimic Tor Browser's behavior for the existing sandboxed-tor-browser + hardened users (Though "too bad, the alpha is now forcing you to reinstall, hope you backed up your bookmarks" is easy.).

I went and filed #21912 (closed) to track sandbox related changes that are required by this.

Replying to yawning:

Users will get updated to the alpha which will hopefully have selfrando included then (depends on getting #20683 (moved) fixed in time).

How's this going to work? (In detail from the perspective of the updater.)

Or more to the point, is it still just "download an XML file, download + apply a MAR"? Where's the channel change notification? If possible I'd like to mimic Tor Browser's behavior for the existing sandboxed-tor-browser + hardened users (Though "too bad, the alpha is now forcing you to reinstall, hope you backed up your bookmarks" is easy.).

We would keep the current infrastructure but the XML file for the hardened release would now point to the full en-US alpha MAR file. The full MAR update would then get rid of all the hardened related components. The update channel gets updated with the full MAR file as well and the user profile itself remains mainly untouched (with some exceptions). So, we should be good in that regard if I have all of the pieces correctly in my head. boklm might know more and could correct me if I am wrong.

One interesting part is the locale situation as the hardened series allows the user to choose from much more locales for their Tor Browser. I think we don't have good means ready to give the users the bundle that matches the chosen locale. Taking that into account (and the fact that we are in alpha territory anyway) switching to an en-US Tor Browser seems not too bad. And I guess that should not break the Tor Browser either as the old language packs will just stop working and the en-US one will take over. Again, I could be wrong here but mcs/brade would know more in that case I think and could correct me.

Trac:
Cc: N/A to boklm, mcs, brade

Yes, I think we can point to the alpha version in the XML files in the hardened channel. One thing I am not sure how to do is changing the channel configuration in the browser (the app.update.channel pref). If I remember correctly, just pointing to an update in an other channel will not change the channel the user is following (but maybe I'm wrong). Maybe mcs and brade have an idea how to do that. If we can't change that easily adding a redirect from the hardened channel URLs to the alpha channel is an other option, but it is annoying to have to keep this redirect for an unlimited time.

Replying to gk:

One interesting part is the locale situation as the hardened series allows the user to choose from much more locales for their Tor Browser. I think we don't have good means ready to give the users the bundle that matches the chosen locale. Taking that into account (and the fact that we are in alpha territory anyway) switching to an en-US Tor Browser seems not too bad. And I guess that should not break the Tor Browser either as the old language packs will just stop working and the en-US one will take over. Again, I could be wrong here but mcs/brade would know more in that case I think and could correct me.

Yes, I think that is what will happen. I guess the user might get a mix of languages because the bundled extensions (e.g., Torbutton, Tor Launcher) include all languages. Not the end of the world though.

Replying to boklm:

Yes, I think we can point to the alpha version in the XML files in the hardened channel. One thing I am not sure how to do is changing the channel configuration in the browser (the app.update.channel pref). If I remember correctly, just pointing to an update in an other channel will not change the channel the user is following (but maybe I'm wrong). Maybe mcs and brade have an idea how to do that.

As things stand today, the update channel will be preserved. This is because the mar file generation process generates add-if-not instructions for the channel-prefs.js file, which is where the app.update.channel pref value comes from (and add-if-not will prevent the updater from overwritin an existing file). We should find out how Mozilla transitioned the WinXP users from the release channel to esr in the Firefox 52 timeframe and so something similar if possible.

If we can't change that easily adding a redirect from the hardened channel URLs to the alpha channel is an other option, but it is annoying to have to keep this redirect for an unlimited time.

Agreed.

Here is the relevant Firefox bug (I have not read enough yet to understand exactly what they did): "Create custom MAR to switch Firefox XP/Vista users to ESR52" https://bugzilla.mozilla.org/show_bug.cgi?id=1315083

boklm: do you feel you can take a look at the Mozilla bug in the previous comment and figure out what we need to do on our side to get hardened users properly onto the alpha channel?

Trac:
Status: new to needs_information

Replying to gk:

boklm: do you feel you can take a look at the Mozilla bug in the previous comment and figure out what we need to do on our side to get hardened users properly onto the alpha channel?

Yes, I think I can do that.

What they did was create a mar file that only updates the update-settings.ini and defaults/pref/channel-prefs.js files to switch them to the esr channel. So the update to the next version is done in two steps.

I think we can do the same. After being switched to the alpha channel, hardened users will get an error with the incremental update (as we can't differentiate users of the alpha and hardened versions at that point, and the incremental mar files will only apply to the alpha version), but full update should work.

I will make a mar file for this to try it.

Replying to boklm:

Replying to gk:

boklm: do you feel you can take a look at the Mozilla bug in the previous comment and figure out what we need to do on our side to get hardened users properly onto the alpha channel?

Yes, I think I can do that.

What they did was create a mar file that only updates the update-settings.ini and defaults/pref/channel-prefs.js files to switch them to the esr channel. So the update to the next version is done in two steps.

I think we can do the same. After being switched to the alpha channel, hardened users will get an error with the incremental update (as we can't differentiate users of the alpha and hardened versions at that point, and the incremental mar files will only apply to the alpha version), but full update should work.

I will make a mar file for this to try it.

How did the test go? Are we ready for that?

I made a mar file for switching a browser to the alpha channel and signed it: https://people.torproject.org/~boklm/bug_20814/switch-to-alpha.mar

To test it I set this url as app.update.url.override in a 7.0a2-hardened browser: https://people.torproject.org/~boklm/bug_20814/hardened/switch-to-alpha.xml

The browser found an update, and after applying it the channel was changed to alpha, so it seems to be working.

This is slightly off topic, but with an ESR52-based browser you can no longer use app.update.url.override. Instead you need to override the default value of app.update.url. Search the following page for Scratchpad to learn how: https://developer.mozilla.org/en-US/docs/Mozilla/Setting_up_an_update_server

Replying to mcs:

This is slightly off topic, but with an ESR52-based browser you can no longer use app.update.url.override. Instead you need to override the default value of app.update.url. Search the following page for Scratchpad to learn how: https://developer.mozilla.org/en-US/docs/Mozilla/Setting_up_an_update_server

That's good to know for testing of future versions. Thanks.

Users of the hardened channel are now switched to the alpha channel. Before doing that the updater should show them this bilboard page: https://aus1.torproject.org/torbrowser/update_2/bug_20814.html

Replying to boklm:

Users of the hardened channel are now switched to the alpha channel. Before doing that the updater should show them this bilboard page: https://aus1.torproject.org/torbrowser/update_2/bug_20814.html

Thanks, it did it for me. We are done here I think. There is no hardened Tor Browser anymore: https://blog.torproject.org/blog/discontinuing-hardened-tor-browser-series.

Trac:
Resolution: N/A to fixed
Status: needs_information to closed

closed

moved to tpo/applications/tor-browser#20814 (closed)