Hi, it's Ryan. Package managers partially automate the process of installing and removing software packages. Most package managers use cryptographic signatures to verify the integrity of packages. In the article Attacks on Package Managers, the authors describe how an attacker can abuse package managers that use digital signatures.

Most operating systems have package managers, but UNIX-like systems use them extensively to manage packages on an installed system. Some examples of system-wide package managers (we're purposely avoiding application-specific package managers in this post) are APT, Portage, and YUM. There are a lot more, though--Wikipedia has a partial list of others.

Many of these package managers use cryptographic signatures to verify the integrity of packages. The Debian Wiki describes how APT uses GPG to check packages, and other package managers behave in a similar way.

What problems can the attacker cause by gaining control of a mirror? Completely shutting down the mirror server would be easy for users to notice. A more subtle attack would be to distribute packages that are signed but still contain vulnerabilities. How can a package be both signed and vulnerable? Well, before CVE-2008-0166 was discovered, OpenSSL (OpenSSL versions 0.9.8c-1 to 0.9.8g-9 on Debian-based systems to be precise) did not have any publicly known vulnerabilities. After discovery, OpenSSL had well-known problems, and, until they were updated, SSH servers (OpenSSH uses OpenSSL) were vulnerable. However, the vulnerable version is still a valid signed package. Assuming that a user is obtaining security updates from a third-party mirror, that mirror could pass the user signed packages with known vulnerabilities.

Before going any further, it's worth pointing out that this problem isn't limited to open-source vendors. Any software that gets updates via the internet (just about all software) could be affected. However, exploitation is much more difficult when the software vendor directly controls the mirrors--before attacking clients, an attacker needs to locate and take control of the mirror. Many open-source projects make it simple for third parties to become mirrors.

So, we've talked about the problem and why it is somewhat of a concern for vendors that don't directly control their mirrors. As far as we can tell, no mirror site has intentionally given clients packages with known vulnerabilities and then exploited those vulnerabilities. Furthermore, there are several things mirror users and administrators can do to protect themselves:

• Administrators can avoid using third-party repositories by running locally hosted mirrors, setting up caches, or getting packages from a trusted source. It is important to note that exploits can be created rapidly, so even a small delay in getting fixed software can be problematic.
• When third-party repositories need to be enabled, users should select their repositories carefully. How long has the mirror been around? Is it up to date? Is it easier to get the package from another source (such as the developer's home page)? Does the operating system vendor track the repo?

Projects use mirrors to reduce bandwidth costs and provide redundancy. How can software maintainers offer secure mirrors that aren't slow and unstable? Some commercial Linux distributions offer high-speed direct downloads from trusted sources. Another potential solution to this problem is P2P technology. If widely used, programs like DebTorrent may allow official repositories to distribute metadata and tracker information while decreasing bandwidth costs.

The issues we've talked about (mirror distribution, software integrity) are a subset of the larger problem of obtaining, installing, and managing trusted software. The importance of obtaining verified, trusted packages needs to managed according to your security policy.

Thanks to Justin Cappos and Justin Samuel for providing us information about these issues. A special thanks to all the vendors who gave us feedback.

If you send us mail, we are tracking these issues as VU#230187.