[Secure-testing-team] Bug#752275: torbrowser-launcher: several possible/probably security issues

[Christoph Anton Mitterer]

Package: torbrowser-launcher
Version: 0.0.7-1
Severity: grave
Tags: security
Justification: user security hole


Hi.

This is basically a follow up from the lengthy discussion at 
debian-devel:
https://lists.debian.org/debian-devel/2014/06/msg00171.html
(somewhere deeper in the thread).

Admittedly I didn't read through the whole code of torbrowser-launcher.
Some of the issues below might be mitigated when e.g. no locally
downloaded browser would be ever started when the launcher couldn't connect
online to check for new versions... but that would mitigate the
downgrade attacks described below ONLY if connections to the server are
only made via SSL/TLS and if that doesn't allow replaying.
Given that TLS/SSL is very... uhm.. fragile... I wouldn't trust on this.
And one would need to check specifically for a X.509 cert that is known
to belonging to Tor,... checking for just some CA would still allow attacks.

Anyway... the problem described below, that any Tor upstream developer
whose key is accepted by that launcher can introduce any code in a Debian
system, is imho already critical enough.


AFAICS, torbrowser-launcher uses the gnupg keys from upstream
to verify the downloaded executables.
As already pointed out in the aforementioned thread, this has
several critical security issues:

- anyone from these upstream people, whose key is included, and
who are not DDs, can in principle introduce any software they like
into the Debian system of any single user or all users.
This is especially problematic, since it allows selective attacks on
single users, which are not possible via the package management system
where it's guaranteed, that all users will download the same binaries,
which in turn increases the chance that any backdoor/etc. is found.

- since it automatically determines the most recent version and downloads
it, it completely circumvents the package management system.
People won't notice via their usual means (aptitude, or other notifiers)
that there are newer versions (possibly fixing critical security issues)
unless they run the torbrowser-launcher again?
(or is it always run via that?)

- another really big problem are blocking/downgrade attacks.
AFAICS from a shore glance, there is no (cryptographically secured) check
as to whether the information from the server (i.e. the currently most
recent version) is really current, i.e. a "valid from-through information".
This should allow attackers very easily to perform replay/downgrade attacks
tricking people into downloading old versions with already known security
issues.
Since thes are signed with valid keys (but AFIACS with no valid from/through
information) the downloader will just happily accept them.
I'm not sure, but I guess it doesn't help if you download things via https.
Another issue are blocking attacks... when no connection can be made at all
to the tor download servers, will it start the currently downloaded version
of the bundle or will it simply fail? In case it doesn't fail, it could
again be used to trick people into using software with known security
deficiencies.



Such "downloader packages" are quite danerous per se,... as it's very
tricky to really securely do it.
Usually the best way is to hard code a secure hash (i.e. not MD5) of
the upstream package which is currently considered secure... every time
a new upstream version comes out, a new downloader package should come
out as well with a new hash,...so that people regularly (via the package
management system) notice about [security] updates.




Cheers,
Chris.


btw:
Apart from that... I've always wondered how secure something like
torbrowser bundle can be... per se, they will always lag a bit behind
FF with security updates,... and FF in turn already has enough security
issues.

btw2: Since torbrowser-launcher is probably usually launched as
normal user, I marked this as "user security hole" only.
But given that torbrowser-launcher will typically be run on
desktops/notebooks... successfully attacking that user is usually
equivalent to root exploit (the attacker could simply wait for
the user to sudo/su to root and keylog his password).
So actually severity is IMHO critical.