A Look In the Mirror: Attacks on Package Managers Justin Cappos Justin Samuel Scott Baker John H. Hartman Department of Computer Science, University of Arizona Tucson, AZ 85721, U.S.A. {justin, jsamuel, bakers, jhh}@cs.arizona.edu ABSTRACT systems [1, 2, 3, 21, 22, 25, 26, 28, 31, 32]. Package managers This work studies the security of ten popular package man- provide a privileged, central mechanism for the management agers. These package managers use different security mech- of software on a computer system. As packages are installed anisms that provide varying levels of usability and resilience by the superuser (root), their security is essential to the to attack. We find that, despite their existing security mech- overall security of the computer. anisms, all of these package managers have vulnerabilities This paper evaluates the security of the eight most popu- that can be exploited by a man-in-the-middle or a malicious lar [9, 19] package managers in use on Linux: APT [1], APT- mirror. While all current package managers suffer from vul- RPM [2], Pacman [3], Portage [21], Slaktool [25], urpmi [28], nerabilities, their security is also positively or negatively im- YaST [31], and YUM [32]. Also examined is the popular pacted by the distribution’s security practices. Weaknesses package manager for BSD systems called ports [22] and a in package managers are more easily exploited when distri- popular package manager in the research community called butions use third-party mirrors as official mirrors. We were Stork [26]. These package managers use one of four differ- successful in using false credentials to obtain an official mir- ent security models: no security, cryptographic signatures ror on all five of the distributions we attempted. We also embedded within packages, signatures on detached package found that some security mechanisms that control where a metadata, or signatures on the root metadata (a file that client obtains metadata and packages from may actually de- contains the secure hashes of the package metadata). crease security. We analyze current package managers to This work demonstrates that there is an ordering to the show that by exploiting vulnerabilities, an attacker with a amount of security provided by the different package man- mirror can compromise or crash hundreds to thousands of ager security models. This order is preserved even as other clients weekly. The problems we disclose are now being cor- security weaknesses in the package managers are corrected. rected by many different package manager maintainers. Having no signatures allows the most egregious attacks, fol- lowed by having only package signatures, having signatures on detached package metadata, and finally having signa- Categories and Subject Descriptors tures on the root metadata, which provides the most secu- K.6.5 [Security and Protection]: Invasive software; C.2.0 rity. However, there are usability concerns with different [Computer-Communication Networks]: General—Se- signature mechanisms, most notably the ability to verify a curity and protection; K.4.1 [Social Issues]: Abuse and stand-alone package (a package obtained from a source other Crime Involving Computers than the main repository). Signatures on root metadata do not provide a convenient way to verify stand-alone packages General Terms and so the user is likely to install such packages without us- ing security checks. In contrast, package managers that use Security signatures on detached package metadata or signatures on packages can verify stand-alone packages. Keywords Because of the usability strengths and weaknesses of dif- Package Management, Mirrors, Replay Attack ferent techniques for providing security, this work recom- mends a layered approach created by combining two tech- 1. INTRODUCTION niques: signatures on the root metadata and either signa- tures on packages or package metadata. This technique pro- Package managers are a popular way to distribute software vides the security strengths and the usability strengths of (bundled into archives called packages) for modern operating both types of signatures with an overhead of between 2-5%. The layered approach has been added to the Stork package manager and is now in use by thousands of clients around Permission to make digital or hard copies of all or part of this work for the world. personal or classroom use is granted without fee provided that copies are While we find that vulnerabilities in package managers not made or distributed for profit or commercial advantage and that copies do exist, vulnerabilities are not always exploitable in the bear this notice and the full citation on the first page. To copy otherwise, to real world. We examine this by looking at the security of republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. popular distributions. We find that it is trivial for an at- CCS'08, October 27–31, 2008, Alexandria, Virginia, USA. tacker to control an official package mirror for a popular Copyright 2008 ACM 978-1-59593-810-7/08/10 ...$5.00. distribution (such as Ubuntu, Debian, Fedora, CentOS, and Root Metadata Package openSUSE) and therefore to be in the position to launch at- packagemetadata1 hash: c302df...f8 Metadata tacks on clients. To mitigate this threat, many distributions packagemetadata2 hash: 192ee0...31 packagemetadata1 use mechanisms to distribute requests to multiple mirrors Root Metadata signature (optional) or provide certain information from a trusted source. We A Package A Package’s Metadata show that some of these mechanisms actually decrease the foo−2.0.rpm security of users by making it easier to target attacks. name:’foo−2.0.rpm’ package contents size:’56242’ hash:’74b5a1...c3’ 2. BACKGROUND embedded package ... metadata Package Metadata Package 2.1 Package Formats signature (optional) signature (optional) Packages consist of an archive containing files and, in most cases, additional embedded package metadata. For a given package, the embedded package metadata contains informa- Figure 1: Repository Layout. The root metadata, tion about any other packages that must be installed in or- package metadata, and packages may all optionally der for it to operate (the dependencies), functionality the have signatures depending on the support of the package possesses (what the package provides), and various package manager. Arrows point from a secure hash other information about the package itself. The most popu- to the file it references. lar package format, RPM [23], has space for one signature. Other popular package formats have no standard field for Figure 1 shows the layout of a typical repository. A pack- signatures, although in some cases extensions exist to sup- age manager downloads the root metadata and uses that port signatures [8, 11]. to locate the files containing the package metadata. The package manager then downloads the package metadata. 2.2 Package Managers The package metadata is used to determine package avail- Clients use a package manager to install packages on their ability as well as for dependency resolution. Packages are system. A package manager gathers information about pack- then downloaded and installed. The root metadata, pack- ages available on package repositories. Almost all pack- age metadata, and packages may be signed depending on age managers automatically download requested packages as the security model of the package manager. well as any additional packages that are needed to correctly install the software. This process is called dependency res- 2.4 Mirror olution. For example, a requested package foo may depend It is common for a distribution to have more than one on libc and bar. If libc is already installed, then libc is server from which users can download packages and package a dependency that has been resolved (no package must be metadata. There is usually a main repository for a distribu- installed to satisfy the dependency). If there is no installed tion whose contents are copied by many separate mirrors. package that provides bar, then bar is an unresolved depen- A mirror typically contains exactly the same content as the dency and a package that provides bar must be installed main repository and is updated via rsync or a similar tool. before foo may be installed. The package manager may be A mirror differs from a main repository in that a mirror is able to locate a package that provides bar on a repository. not intended to have packages directly added to it or re- The packages that are chosen to fulfill dependencies may moved from it by its administrators. Packages are added or have unresolved dependencies of their own. Packages are removed only on the main repository and the mirrors later continually added to the list of packages to be installed until obtain the changes when copying the main repository. either the package manager cannot resolve a dependency A mirror can be public (available for anyone to use) or (and produces an error) or all dependencies are resolved. private (restricted to a specific organization). A mirror may also be endorsed by a distribution for public use, typically 2.3 Repository when that the distribution is in contact with the mirror A package repository is usually an HTTP or FTP server maintainers. This type of mirror is called an official mirror from which clients can obtain packages and package meta- (the terminology used outside of this document varies by data. The package metadata is usually just a copy of the em- the distribution). Official mirrors are by definition public bedded package metadata for all packages on the repository. because the distribution is endorsing their use to the public. Package managers download the package metadata from a It should be noted that some distributions do not use of- repository so that they know which packages are available ficial mirrors hosted by outside organizations. One example from that repository. This also provides the package man- is tiny distributions that can support all of their clients by ager with dependency information needed to perform de- a small number of repositories that the distribution directly pendency resolution.