Re: [tor-dev] Tor Browser Launcher - applying TUF threat model

[adrelanos <adrelanos@xxxxxxxxxx>]

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.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev