Security

Attacks on package managers

It is common for users to use package managers to update their system without considering the security implications. Unfortunately, the security of the package manager matters a great deal because it runs as root and a poor implementation might lead to installation of insecure or malicious packages. Last year, Justin Samuel of the University of Arizona and Justin Cappos of the University of Washington did an extensive research on vulnerabilities of the most common package managers for Linux. In the February 2009 issue of the USENIX magazine ;login:, they published an overview of their findings [PDF]. Although none of the attack methods and vulnerabilities they talk about are particularly new or surprising, the issues are serious enough to merit some attention.

Essentially, there is just one underlying method to all vulnerabilities in package managers: an attacker, rather than a legitimate repository of the distribution, responds to a client when the package manager downloads files. The simplest way to do this is of course becoming a public mirror for a distribution's repositories. When an attacker runs a mirror, he can reply to client requests with malicious content. Thus one question every user has to ask himself is: do you trust the mirrors you use? There was a lot of discussion about the security of mirrors last year and some responses by Linux distributions that were mentioned in the study.

The researchers looked at APT (used by Debian and Ubuntu), APT-RPM (used by PCLinuxOS), Pacman (used by Arch Linux), Portage (used by Gentoo), Slaktool(used by Slackware), Stork (a research project of the University of Arizona), URPMI (used by Mandriva), YaST (used by openSUSE and SUSE Linux Enterprise) and YUM (used by Fedora, Red Hat Enterprise Linux and CentOS). They didn't look at BSD systems for this research, although they are currently investigating the Portsnap tool for securely distributing the FreeBSD ports tree.

Cryptographic signatures

A vulnerability in a package manager can mean two things: either it installs a package the user doesn't want to install, such as an older, vulnerable version of the package or a dependency that isn't needed but hosts a Trojan horse; or it doesn't install a package the user wants to install, such as a security update. To make these events impossible, package managers can use cryptographic signatures. The differences in package managers largely come down to what is actually signed: the root metadata, the metadata that describes the packages, or the packages themselves.

The root metadata is the first file that a package manager downloads, which describes the contents and the layout of the repository, usually with the names and hashes of the files that have detailed information. If the root metadata is signed, the package manager can check if someone is tricking it into downloading a fake root metadata file. By verifying the integrity of the root metadata and then verifying the secure hashes of each downloaded file, the package manager is able to check the integrity of the information. This model is used by APT, APT-RPM and YaST.

Another approach is placing signatures on the files that directly contain the metadata of the packages, as Portage does. A third way is to not have signatures on the metadata, but on each individual package. Package managers like YUM and URPMI download a package and then check the signature before installing it. But even if the package manager uses one of these three types of cryptographic signatures, this doesn't mean it is safe.

The vulnerabilities

The possible vulnerabilities of package managers fall into three main categories: replay and freeze attacks, metadata manipulation attacks and denial-of-service attacks. A replay attack comes down to the following: when a package manager requests signed metadata, a malicious party responds with an old signed file. This is possible without the need to compromise the signing key, because once a file is signed, it is always trusted by clients. This works even after vulnerabilities are discovered in a package that was once considered safe: the attacker just has to respond with old metadata that lists package versions the attacker knows how to exploit. A freeze attack works in a similar way: an attacker keeps giving the client the same version of the metadata, essentially "freezing" the metadata at one point in time to prevent updates to vulnerable packages.

With a replay attack, the attacker is still rather limited in what he can do: he can only respond with packages from a single point in time. This means that if two packages were vulnerable at different times, the attacker cannot make both vulnerable versions available to the client with a replay attack. If the package manager does not use signed metadata, an attacker doesn't have to bother with a replay attack: the system is at risk because the attacker can just make up his own metadata. In one attack, he can make as many vulnerable packages available to the client as he wants, and thus he can increase significantly the chances of a client installing and using a vulnerable package.

If an attacker has the chance to manipulate metadata, he can also lie to the clients about what a package requires. If a package has a vulnerability the attacker knows how to exploit, he can provide metadata that says every package depends on this package. This ensures that the client installs it when installing any other package. Only a user with intimate knowledge of the packages and their dependencies will spot this.

The last category of vulnerabilities are the endless data attacks, which essentially are a form of denial-of-service. This attack is dead simple: the malicious party responds to a client request (metadata or a package) with an endless stream of data. Possible results are filling up the partition or exhausting memory.

What are the distributions doing about it?

Samuel and Cappos give a good overview of the security of the different package managers and distributions. Their paper outlines the situation from last year, so it's good to look at what has been done in the meantime. At one end of the spectrum, Slaktool on Slackware, Pacman on Arch Linux and Ports in the BSD world don't make any pretense of being secure. Justin Samuel said that he has the impression that the Slackware community is not currently focused on securing their package manager, but Arch Linux has an open bug related to adding support for signed packages and there has been community discussion following the publication of their research from last year.

Then there are the package managers that don't use signatures on root metadata, such as YUM, URPMI and Portage. These are all vulnerable to metadata manipulation attacks and hence not very secure. Since the study YUM developers have added the ability to use signed root metadata, but Fedora 10 is not using it yet and the mirrors don't contain root metadata signatures. The YUM developers are working on some of the other security issues, but it's not yet clear whether the changes will be part of Fedora 11.

Gentoo's Portage developers have also begun to address these vulnerabilities and are in the planning stage for adding a signed root metadata file to Portage. Gentoo Linux Enhancement Proposal 58 discusses the addition of what Gentoo calls a MetaManifest. The proposal is listed as having Draft status.

During the research of Samuel and Cappos, all package managers were vulnerable to replay and freeze attacks, but package managers that signed either the root metadata or package metadata don't require many changes to address this issue. This includes YaST and APT. Debian's APT developers have begun planning the necessary changes. A first attempt at a solution to replay attacks was added to experimental, and will probably be implemented in an upcoming point release of Lenny.

The endless data attacks also affected all package managers, and none has solved this at the moment. Samuel and Cappos have implemented protections against all of the attacks mentioned for Stork, their own package management system.

The authors warn that using a secure package manager doesn't mean that the distribution is using these security measures. One notable example is PCLinuxOS, which uses APT-RPM but doesn't make use of its support for root metadata signatures. And although the YUM developers have responded quickly by adding support for signed root metadata, distributions using YUM do not yet sign this metadata.

The verdict: use an enterprise Linux distribution

The best way to stay secure is to choose a distribution that takes these vulnerabilities seriously. The findings of the study show, unsurprisingly, that using an enterprise Linux distribution is a serious security advantage: SUSE Linux Enterprise and Red Hat Enterprise Linux are not vulnerable for these attacks, not because they have specifically protected against these attacks, but because of their use of SSL (which blocks man-in-the-middle attacks if correctly implemented) and by not using public mirrors.

The authors also praise openSUSE for offering almost the same level of protection as the enterprise distributions. According to Justin Samuel, openSUSE is the most secure community distribution due to only being vulnerable to man-in-the-middle attacks, and not from malicious mirrors. YaST supports expiry of metadata in openSUSE 11.1, but the metadata in the official update repository has no expiry time set at this time. According to Ludwig Nussel from the openSUSE security team, this will be fixed soon.

The authors have an accompanying web site with more background about package manager security and access to more papers.

Comments (16 posted)

New vulnerabilities

bugzilla: cross-site request forgery

Comments (none posted)

clamav: denial of service

Comments (none posted)

device-mapper-multipath: incorrect permissions

Comments (none posted)

horde3: multiple vulnerabilities

Comments (none posted)

kernel: denial of service

Comments (none posted)

kernel: multiple vulnerabilities

Comments (none posted)

lcms, java: denial of service

Comments (none posted)

mapserver: multiple vulnerabilities

Comments (none posted)

moodle: arbitrary file access

Comments (none posted)

openfire: multiple vulnerabilities

Comments (none posted)

openssl: several vulnerabilities

Comments (none posted)

php: cross site scripting vulnerability

Comments (none posted)

tunapie: several vulnerabilities

Comments (none posted)

xpdf: arbitrary code execution

Comments (none posted)

Page editor: Jake Edge
Next page: Kernel development>>