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. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
