Citing: https://www.updateframework.com/wiki/Docs/Security#AttacksandWeaknesses
Arbitrary software installation. An attacker installs anything they
want on the client system. That is, an attacker can provide arbitrary files in response to download requests and the files will not be detected as illegitimate.
No idea about this one.
Rollback attacks. An attacker presents a software update system with
older files than those the client has already seen, causing the client to use files older than those the client knows about.
This would be a non-issue with Jacob's recommendation: "never allow a valid signature with a lesser version number".
Indefinite freeze attacks. An attacker continues to present a software
update system with the same files the client has already seen. The result is that the client does not know that new files are available.
Not sure about this one.
I think it gets somewhat circumvented by downloading over Tor, i.e.
user <-> user ISP <-> Tor <-> torproject.org ISP <-> torproject.org MITM less likely for this route | mitm still possible
Ok, if downloading over Tor...
What about downloading form the torproject.org hidden service? http://idnxcnkne4qt76tg.onion/
It would never leave the Tor network and even an adversary in position to take down the torproject.org domain, couldn't stop updating.
Endless data attacks. An attacker responds to a file download request
with an endless stream of data, causing harm to clients (e.g. a disk partition filling up or memory exhaustion).
Slow retrieval attacks. An attacker responds to clients with a very
slow stream of data that essentially results in the client never continuing the update process.
How to defend these two?
Will pinning the SSL certificate do the job or should a timeout be added to the download? (I think it depends on if mirrors will be used.)
Extraneous dependencies attacks. An attacker indicates to clients that
in order to install the software they wanted, they also need to install unrelated software. This unrelated software can be from a trusted source but may have known vulnerabilities that are exploitable by the attacker.
A non-issue for Tor Browser Launcher, dependencies are managed by the debian package manager, which isn't vulnerable to this. Tor Browser Launcher itself does not have dependency management. No action required.
Mix-and-match attacks. An attacker presents clients with a view of a
repository that includes files that never existed together on the repository at the same time. This can result in, for example, outdated versions of dependencies being installed.
Wrong software installation. An attacker provides a client with a
trusted file that is not the one the client wanted.
Not sure about these two, but according to the historic TUF papers, SSL (and pinning even more) defeats this. Thus, a hidden services, since also encrypted end-to-end should also defeat this.
Thandy would be ideal again, but for now, pinning SSL or using the hidden service should be fine.
Malicious mirrors preventing updates. An attacker in control of one
repository mirror is able to prevent users from obtaining updates from other, good mirrors.
Currently no mirrors are not being used. This itself isn't ideal and would welcome Thandy again, but for now, no action required.
Vulnerability to key compromises. At attacker who is able to
compromise a single key or less than a given threshold of keys can compromise clients. This includes relying on a single online key (such as only being protected by SSL) or a single offline key (such as most software update systems use to sign files).
This can only be solved with Thandy, TUF or similar. I think it's a bit far fetched for now, so no action required.
extra by adrelanos: 'permanent takedown' threat described it here:
https://mailman.boum.org/pipermail/tails-dev/2013-January/002396.html
summary: an adversary takes the main repository offline. The TUF people said they are interested in this 'permanent takedown'
threat, not sure if TUF defends it at the moment and want to answer me in a week or so if TUF
Also a bit far fetched for now, defeating this and using TUF/Thandy would be ideal, but for now, no action required.
By the way, the TUF website (Contact) has also a mailing list with friendly people, which could be asked in doubt. Unfortunately, it does not seem to have public archive.