Sorry for the late reply.
On Sat, 2014-06-21 at 23:01 -0700, Micah Lee wrote: > 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 Well who they are and which names they have doesn't really matter, does it? I think the only thing that is important here: at least not all of them are DDs > > - 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. From what you describe it just means that any of the above people could sign any piece of software, place it at https://www.torproject.org/ and distribute it (even selectively per possibly specifically attacked user) to Debian systems. Just as I've said - or do I understand anything wrong? > 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. As I described in the end of my ticket: On those systems that probably will use TBB (i.e. desktops, notebooks) gaining user access is typically identical to gaining root access (even if there wouldn't be any privilege escalation bugs). If the user acc is taken over, a malicious software would simply install some keylogger or whatever and wait until the user sooner or later switches user to root. And as you've said, introducing code with just user rights *is* bad enough ;) > > 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? *If* Tor developers would be evil (and I'm not saying this - I rather just think they're not DDs and should therefore not have this potentialpower)... they can probably return different binaries to http[s] requrests based on the downloading client (e.g. via IP address). So it would be possible to deliver malicious code to just a portion of the downloading users... which would make such an attack even more difficult to detect. > Are you assuming that the attacker has access to one of the Tor devs > trusted signing keys listed above I neither claim that this is the case, nor do I say that the Tor upstream people are "evil" and would misuse their powers ;-) But you can never know... keys can be compromised... and people can be forced to do things (especially in countries like the US - with national security letters and gag orders). And I think it's simply what one can/should expect when installing a Debian package: That all software directly/indirectly installed by it went thorough the hands of some DD or DM (who decided what gets in - and not some upstream developer)... AND to be sure, that what you get is the same on all Debian systems. > and that the attacker either has > access to the https://www.torproject.org/ web server Well TLS/SSL are known to have many issues (not to talk about those not yet discovered)... so generally we should try to avoid depending on them for hard security... Next things is: The tor servers seem to use a digicert X.509 cert... DigiCert Inc in turn is US based - now guess which country has some organisations constantly trying to undermine Tor and who can probably easily force DigiCert to issue a forged certificate? ;-) The only thing around that would be to hardcode the server cert itself in the launcher program ... and as far as I can see... you do just that. But how did you get that cert? Just via downloading it? Or somehow securely ;) > > - 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. What happens if the torservers can't be contacted? [Edit: answered below] > > - 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 Okay that's good. > Tor Project doesn't provide "valid from-through information", so > replay/downgrade attacks could be attempted. I just wonder myself whether this is acutally possible... or whether TLS contains time information so that replaying is not possible... but I must admit I don't know that. > 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 Uhm I don't understand that. What I mean with "downgrade attack"... is that an attacker captures the correctly signed _OLD_ versions of TBB and RecommendedTBBVersions man-in-the-middles you and make you believe that you're still running the newest and safe version, while in reality a newer one has been released possibly fixing critical issues. I wouldn't see how this could be prevented without any valid from/through information in the RecommendedTBBVersions file,.. especially just checking installed_version < or > latest_version shouldn't help. As said just above,... using TLS could prevent this... and some short googling implies it may actually does - though it seems to not use the time for this, which makes me a bit uncertain. So the combination of hard coded Tor server X.509 cert (in contrast to the CA root cert) + RecommendedTBBVersions + TLS _possibly_ already securing against replay attacks.... ...may already secure us against downgrade attacks. > It simply fails. An attacker that can block access to > https://check.torproject.org/ can prevent torbrowser-launcher from > launching the browser. Okay that's very good, since it should secure us against blocking attacks. > 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. Mhh okay... possibly have to take things back... This may again introduce blocking and even downgrade attacks,... since if the launcher works if https://www.torproject.org/ is [partially] blocked... you cannot read a RecommendedTBBVersions for which you know it's current - can you? > > 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. mhh... well I'm still quite reluctant... Apart from the open questions above - the way the launcher does it may actually prevent most problems I've described... but therefore it's complex code which makes it error prone,... it depends on many factors to be secure (especially TLS/X.509)... But you may be right that hard coded hashes take too long. Another approach may be what Bart is doing for the flashplayer nonfree plugin (if though that might have as well security issues: #752277) What he tries to do now (AFAICS) is not hard coding the hashes of the plugin in the package directly, but on his directory on some Debian server... and that information in turn is signed by his key. So he doesn't have to wait for new versions of the package to be uploaded to the archive, but it's still HIM who controls which binaries are signed and accepted in Debian. I still don't like this approach very much, though,... I think even such launcher/downloader packages should provide behaviour that is more or less the same to normal packages... i.e. you should see and get upgrades via the package management system. And are you really sure that the normal way for package updates is really too slow? I mean most other packages get their security updates quite fast. btw: AFAIU, there is no mode of the launcher where TBB is installed system wide, right? It's always just for the local user? > 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 That would also allow us to put it in main, right? > 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. Sure... that would be much worse... Well perhaps we can try to clear out the last remaining questions from above (like about possible issues in "mirror-mode")... But apart from that... well *if* TLS prevents against replay attacks, I agree that at least blocking/downgrade attacks shouldn't be possible. (Of course, important part is that you really hardcode the X.509 server cert and don't believe the CA). I still don't fully like that possibly evil Tor developers (or more likely: by the US government forced Tor developers) would be able to introduce any code even selectively to users... as well that the launcher basically circumvents the usual ways of update notifications and package management (i.e. system wide installation)... but at least you are notified on every start and if it really aborts if the tor webservers can't be checked... then I do not see any big security issues. Well... I'd still like a natively packaged TBB or downloader package using simple static hashes more... ;) Even if it will possibly turn out now, that things are already quite okay, I think it was worth going through that and having it evaluated, thx for that. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
