Your entire download infrastructure needs to use HTTPS

April 8, 2015

Let's start with something that I tweeted:

Today's security sadface: joyent's Illumos pkgsrc download page is not available over https, so all those checksums/etc could be MITMd.

Perhaps it is not obvious what's wrong here. Well, let's work backwards. The Joyent pkgsrc bootstrap tar archive is served over plain HTTP, so a man in the middle attacker can serve us a compromised tarball when we use curl to fetch it. That's obvious, and the page gives us a SHA1 checksum and a PGP key to verify the tarball. But the page itself is served over over plain HTTP, so the man in the middle attacker could alter it too so it has the SHA1 checksum of their compromised tarball. So surely the PGP verification will save us? No, once again we are undone by HTTP; both the PGP key ID and the detached PGP ASCII signature are served over HTTP, so our MITM attacker can alter the page to have a different PGP key ID and then serve us a detached PGP ASCII signature made with it for their compromised tarball.

(Even if retrieving the PGP key itself from the keyserver is secure, the attacker can easily insert their own key with a sufficiently good looking email address and so on. Or maybe even a fully duplicated email address and other details.)

There's a very simple rule that everyone should follow here: every step of a download process needs to be served over HTTPS. For instance, even without PGP keys et al in the picture it isn't sufficient to serve just the tarball over HTTPS, because a MITM attacker can rewrite the plaintext 'download things here' page to tell you to download the package over HTTP and then they have you. The entire chain needs to be secure (and forced that way) and from as far upstream in the process as you can manage (eg from the introductory pkgsrc landing page on down, because otherwise the attacker changes the landing page to point to a HTTP download page that they supply and so on).

Of course, having some HTTPS is better than none; it at least makes attackers work harder if they have to not just give you a different tarball than you asked for but also alter a web page in flight (but don't fool yourself that this is much more work, not with modern tools). And it's good to not rely purely on HTTPS by itself; SHA1 checksums and PGP signatures are at least cross-verification and can detect certain sorts of problems.

By the way, in case you think that this is purely theoretical, see the case of some Tor exit nodes silently patching nasty stuff into binaries fetched through them with HTTP. And I believe that there are freely available tools that will do on the fly alterations to web pages they detect you fetching over insecure wireless networks.

(I don't feel I'm unfairly picking on Joyent here because clearly they care not just about the integrity of the tarball but also its security, since they give not just a SHA1 (which might just be for an integrity check) but also a PGP key ID and a signature checking procedure.)

Written on 08 April 2015.
« How Ubuntu and Fedora each do kernel packages
Probably why Fedora puts their release version in package release numbers »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Apr 8 01:04:58 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.