New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Signature verification bypass attack #229
Comments
|
This issue has been assigned CVE-2016-3180. |
|
When this issue with GnuPG was discovered in November of 2014, Werner Koch fixed it in various ways. At least Debian backported those fixes to their stable release; I assume more distributions did. If torbrowser-launcher would have used --batch on invocation, GnuPG would have failed instead of creating a security issue. In my opinion, the use of gpg here warrants --batch. Example sessions: And here with a regular, non-detached signature: Quite importantly: only the regular case would have failed, alerting the developers that their invocation was wrong. When it is actually given a non-detached signature, it will continue succesfully even in batch mode. |
as suggested by @DigitalBrains1 to torbrowser-launcher micahflee/torbrowser-launcher#229 (comment)
…ll as sig file into gpg (fixes micahflee#229)
Jann Horn reported a clever security issue that lets an attacker bypass PGP signature verification. Because Tor Browser Launcher uses defense in depth, an attacker would need to combine this attack with other attacks before they could succeed in an exploit. Specifically, they would need to be in a position to man-in-the-middle the download and also defeat the HTTPS connection to https://dist.torproject.org/ or one of the mirrors.
The first time you run Tor Browser Launcher, it works like this:
.tar.xzfile (I'll call it $tarball) and.tar.xz.asc($sigfile), and downloads them both/usr/bin/gpg --homedir $homedir --verify $sigfileThe problem is that
gpg --verifycan be ambiguous. If $sigfile istor-browser-linux64-5.5.3_en-US.tar.xz.asc, it can either mean that that's a detached signature and the content is intor-browser-linux64-5.5.3_en-US.tar.xz, or it can mean that it's the content is included in the same file.If an attacker can MITM connections to https://dist.torproject.org/ or whatever mirror is set, and their MITM server uses a trusted certificate, then they can replace $sigfile with a single file that contains the valid Tor Browser tarball and signature, and replace $tarball with something malicious but completely unsigned. When Tor Browser Launcher downloads $sigfile and verifies it, the verification will succeed and it will extract $tarball and execute
start-tor-browser.desktop, which will let the attack run their arbitrary code as the current user (they could even launch a legit Tor Browser if they want to be stealthy).The solution is to specify the content as well as the signature file when verifying the signature, e.g.:
/usr/bin/gpg --homedir $homedir --verify $sigfile $tarballThe text was updated successfully, but these errors were encountered: