Do you trust this package?

Your distribution’s package manager probably uses GPG signature checking to provide an extremely strong guarantee that the software packages you download have not been maliciously modified by a man in the middle (MITM) attacker when traveling over the Internet from your distribution to you. Smaller distros might have no such infrastructure in place (these distros are not safe to use), but for most major distros, a MITM attack between your distribution and your computer would be very difficult to pull off once your distribution has been installed. (Installing a distribution for the first time is another matter.)

But what guarantee is there that no MITM attacker compromised the tarballs when they were downloaded from upstream by a distro package maintainer? If you think distro package maintainers bother with silly things like GPG signature checking when downloading tarballs, then I regret to inform you that Santa is not real, and your old pet is not on vacation, it is dead.

HTTPS is far from perfect, but it’s much better than no HTTPS, and it is the only effective way to secure packages between upstreams and distributions. Now for an easy game: find an important free software package that is distributed upstream without using HTTPS. Don’t bother with small desktop software either, focus on big name stuff. You have a one minute time limit, because this game would be too easy otherwise. Ready, set, go.

Done? Think about how many different ways exist for an attacker to insert arbitrary code into the tarball you found. HTTPS makes these attacks far more difficult. Webmasters, please take a few minutes to secure your site with HTTPS and HSTS.

8 Replies to “Do you trust this package?”

    1. “Can” doesn’t mean “do”, though. Most distributions have some facility for this, but if you check, you’ll find few packagers actually bother doing it, certainly for every update.

      You also have to worry, of course, about the distribution’s approach to trusting packagers, and each individual packager’s security – people with commit rights to major distros are of course *extremely* attractive targets for attackers, but it’s amazing how few of them have ever thought about this, if you ask ’em. Do they have a dedicated ssh key for pushing to the distro repos that they lock after using and change the passphrase on frequently? No? Oh dear…

  1. As others have suggested, why bother with tarballs at all? The upstream project can declare a particular revision to be the release (either with signed tags in a system such as git, or just in the release announcement) and you get that. The release announcement can be replaced with a fake one, of course, but if you can do that you could equally well change the download location for tarballs.

    It used to be the case that there were things in the source tarball that weren’t in the source tree, such as the ‘configure’ script generated by autoconf. I think that nowadays the distributions would be quite happy to pull the pristine source code and run autoconf as part of the build.

    1. I don’t know about nginx’s hardware, but many open source projects and their mirrors struggle with old hardware that may not have hardware-accelerated TLS implementations. To many popular package archives adding https will simple add too much of a CPU overhead.

Comments are closed.