On 06/21/14 18:55, Christoph Anton Mitterer wrote: > 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:
The keys that are signing keys that are included torbrowser-launcher are for: Alexandre Allaire, Erinn Clark, Mike Perry, and Sebastian Hahn. Keys are here: https://github.com/micahflee/torbrowser-launcher/tree/master/keys > - 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. I don't think these people could introduce any software they like into the Debian system. torbrowser-launcher downloads the TBB software from a predictable location at https://www.torproject.org/ and also downloads the signature for it. If the signature verifies, then it trusts the TBB as being valid and extracts it into the current user's ~/.torbrowser/.tbb folder, and launches ~/.torbrowser/tbb/stable/x86_64/tor-browser_en-US/start-tor-browser (or similar, depending on your architecture, language, and if you're running stable or alpha). It runs this as the current user. So even if the TBB tarball that downloaded was malicious, it would only get code execution as the current user, not as root. They wouldn't be able to, for example, install another debian package. Although arbitrary code exec as the current user is really bad, of course. > 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. How could this be used to do selective attacks against specific users? Are you assuming that the attacker has access to one of the Tor devs trusted signing keys listed above and that the attacker either has access to the https://www.torproject.org/ web server (and Tor's website is configured without CDNs or caching in such a way that they could swap out a legit TBB tarball for a malicious one for a specific IP address making the request), or the attacker has Tor's SSL key and is in a position to do a MITM attack? If those criteria are met, that attack could work. Of course, this is also true of Debian. > - 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?) It's always run via torbrowser-launcher, and it checks for updates on each run. TBB itself doesn't offer any application launchers, and one of the main benefits of torbrowser-launcher is the convenience of being able to easily launch from your desktop environment. > - 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. The current version check is cryptographically secured. It makes a request to https://check.torproject.org/RecommendedTBBVersions, and the request is pinned to Tor Project's SSL certificate (not to a CA, like was mentioned above). Here's the x509 certificate: https://github.com/micahflee/torbrowser-launcher/blob/master/torproject.pem Tor Project doesn't provide "valid from-through information", so replay/downgrade attacks could be attempted. However, downgrade attacks are expliticly checked for, and will fail with an error message saying: "Something is wrong. The version of Tor Browser Bundle you have installed is newer than the current version?" See: https://github.com/micahflee/torbrowser-launcher/blob/master/torbrowser-launcher#L629 > 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. It simply fails. An attacker that can block access to https://check.torproject.org/ can prevent torbrowser-launcher from launching the browser. The settings do letter people try using different mirrors, however, so if https://www.torproject.org/ is blocked they can still download a new version, and it will still have its signature verified. > 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. I considered this at first, but new versions of TBB come out so frequently that this would be quite a lot of work to maintain. I also doubt that it would be as secure. There would be a window of time when Tor Project releases an updated TBB where torbrowser-bundle users won't be able to download the latest version because the update is working its way through the Debian pipeline. > 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. The Tor devs seem to be very much on top of this. I don't think TBB lags behind more than 24 hours when there are Firefox security bugs that affect it. > 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. I think in order to successfully attack torbrowser-launcher to run arbitrary code as the desktop user you would need: 1) One of the Tor dev signing keys that's included 2) The secret SSL key for https://www.torproject.org/ (unless the user is using a mirror) 3) Either be in a position to MITM the user, or have owned Tor's web server To do this same attack against a normally Debian system you only need: 1) The Debian repository signing key 2) Either be in a position to MITM the user, or have owned the repo's web server I agree that having Tor Browser proper, directly from the Tor project, in Debian would be better than using torbrowser-launcher. But unfortunately this is a massive undertaking that would involve doing some wonky things (like adding an iceweasel-src package to the binary repo, so that Tor Browser could apply its extra Firefox patches). In the end, torbrowser-launcher turns out to be by far the most elegant solution. Here's the bug: https://trac.torproject.org/projects/tor/ticket/3994 Without torbrowser-launcher, when Debian users want to use Tor Browser they'll visit https://www.torproject.org/ and download it. Most users probably won't verify the gpg signature, and they'll just trust the CA system that their download wasn't attacked. They'll have to open a terminal and manually run the start-tor-browser script because there's no application launcher. There also won't be any auto-updating, so when they're browser is out of date they'll either just use an insecure version of Tor Browser, or they'll repeat the same steps to download and install it again without verifying the signature or pinning the torproject.org cert. Of course, it's possible for Debian users to manually do all of the things that torbrowser-launcher automatically does, assuming they already know exactly which cert torproject.org uses, and assuming they have the correct TBB signing key (both things that are difficult to get right if you're under an active CA attack, and aren't connected to the Tor dev's keys in the web of trust, or don't know what the web of trust is). -- Micah Lee -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
