Suggestion: update-torbrowser shouldn't downgrade by default

Development
1

For a long time, I’ve only ever used update-torbrowser --onion --noask to update Tor Browser in my whonix-ws template. As discussed in the [download torbrowser via onion - #10 by adw] thread, I recently noticed that the onion address was unreachable, so my Tor Browser wasn’t being updated. So, I dropped the --onion option and ran update-torbrowser --noask. The result was that Tor Borwser was downgraded from 9.5.4 to 9.5.3. In other words, 9.5.4 was already installed, and update-torbrowser uninstalled it in order to install 9.5.3.

I’m a bit confused about why this happened. Since I always run the same command (except for --onion), then shouldn’t it always do the same thing? For example, if the default is to grab the lowest stable version, then since I never override the default, shouldn’t it always grab the lowest stable version? Maybe it actually is doing this, and The Tor Project bumped the lowest version up to 9.5.4, then bumped it back down to 9.5.3 for some reason? Or maybe the onion server (from when I was using --onion) had 9.5.4 as the lowest, while the clearnet server, for some reason, had 9.5.3 as the lowest?

In any case, my suggestion is that perhaps update-torbrowser should never downgrade Tor Browser versions by default. In other words, if the lowest stable version available from the server is lower than what we already have, do nothing.

1 Like
2

It’s hard to know which is the right version.

It uses the lowest version number pointed out in RecommendedTBBVersions because other versions could be alpha or beta versions.

A messy situation worked around with this:

…which are both manual interactive methods, not --noask.

And then there is also the hardcoded version number(s) for the tb-updater in Qubes TemplateVM mechanism.

Thanks for your suggestion. Implementing downgrade protection when using --noask would be rather difficult.

I’ll change the man page from

to

Long term my plan is rather to deprecate tb-updater since it has been causing significant development, support, maintenance effort and to rather use a solution similar to the one for electrum appimage by using package binaries-freedom.

2 Likes
3

I had considered that, but I figured we would want to verify the signatures on the actual bundles themselves in order to determine trusted version numbers anyway, because if we trust the version numbers without authentication, it opens us up to various other attacks, as well. But I suppose downloading and verifying all of the bundles might be considered unfeasible.

Now I am confused why that didn’t prevent update-torbrowser from downgrading from 9.5.4 to 9.5.3. Maybe I hadn’t yet gotten the update in which the hardcoded version got bumped up to 9.5.4?

Now I am even more confused. Reading that, it sounds like updating my whonix-ws-15 template should be automatically updating Tor Browser such that fresh DisposableVMs based on whonix-ws-15 already have updated Tor Browsers. But this does not happen, hence why I had to add update-torbrowser --noask in my own custom update script.

1 Like
4

Bundle signatures are always verified. That authenticates the bundle but version number can’t be authenticated that way. Hence:

Indeed. And even when downloading all bundles, there would still be no way to verify it’s version number. gpg signs files. Not file names. The get a trusted version number we’d have to extract the bundle and then look at some file mentioning the version number inside the extracted archive. Possible in theory but a lot code. At some point the workarounds at downstream (Whonix) are no longer reasonable due to upstream issues (no singed version numbers provided by Tor Project).

Hardcoded version numbers are only used when update-torbrowser script is run from postinst script, i.e. during tb-updater package upgrade.

Yes.

Check:

cat /usr/share/tb-updater/tbb_hardcoded_version

It can fail due to network issues but you’d see this during upgrading. Would have failed if tb_onion=true was set in config folder.

Perhaps would be best to abolish --noask. --noask is not something I have in mind and it’s vulnerable to downgrade attacks. And --noask, automated download, without user oversight, without hardcoded version numbers can’t be made secure with reasonable effort since upstream doesn’t offer authenticated/expiring version metadata. Upstream ticket was created by me years ago.

counter downgrade / stale mirror attacks on RecommendedTBBVersions - sign / verify tbb versions file

There is GETINFO consensus/packages but it’s empty, not populated with actual information yet.

Another option could be making --noask use hardcoded version number. That would be safe. But there is little point since after tb-updater package upgrade it should have cached that version in /var/cache/tb-binary folder already anyhow.

1 Like
5 
tbb_hardcoded_version="9.5.4"

I can check this too, but I’m not sure where to look. I don’t recall modifying it myself.

I can understand that. My personal use case is simply that upgrading TB can take a long time, and I usually don’t remember to do it until I need it, at which point it’s too late. So, it’s much easier if I can just script the update to happen unattended, then I can check the logs afterward (which is how I noticed the downgrade).

1 Like