原文出处：http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html

Overview

Security vulnerabilities are often the result of software bugs. It isimportant to keep software up-to-date, as malicious parties often can exploit bugs in outdated software. Package managers were created to automatethe process of package update and installation, however, if the package manageris not secure, it may represent another avenue of attack!

Package managers are normally run with unrestricted access inorder to allow them to modify critical system software. The packagemanager's actions, therefore, affect the entire system and make thesecurity of package managers vital.

Given their critical role, the expectation would be for package managers to be extremely secure.Weexamined ten popular package managers (APT, YUM, YaST, etc.) for Linuxand BSD systems and found vulnerabilities in all of them. Theattacks discussed here can give attackers the ability to read or eraseany file on your computer, capture passwords, set up a backdoor intoyour system, etc. without needing to compromise any keys or passwords.

Attack Anatomy: Replay Attacks

To provide an example of the sorts of attacks an attacker can launch on packagemanagers, this page describes an example attack called areplay attack.Other attacksare described on a separatepage.

The First Piece: Metadata Replay

Packages are essentially trusted forever once they or repositorymetadata describing them has been signed. This means that even after apackage has a vulnerability discovered in it, clients will continue tobe willing to install that insecure package.An attacker can replaythe correctly signed packages or metadata from a previous release andyour computer will install software with flaws that the attacker canexploit.

The default behavior of package managers is to install the mostrecent version of a requested package that is available from thedistribution. Keeping a client safe would seem to be just a matter ofretrieving the latest repository metadata provided by the distributionon a regular basis.

The Second Piece: Mirror Control

Unfortunately, replay attacks on package managers are still verypossible even if a client frequently requests updated repositorymetadata. The problem is that most distributions use a network ofpublicly provided servers to host their mirrors. In most cases,the people and organizations running these mirrors are only superficially examinedbefore they are listed as an official public mirror. Once listed as apublic mirror, a distribution will begin directing requests to themirror.

To give an example of how easy it is for a malicious party toobtain a mirror, we ran an experiment where we created a fakeadministrator and company name and leased a server from a hostingprovider. We were able to get our mirror listed on every distributionwe tried (Ubuntu, Fedora, OpenSuSE, CentOS, and Debian) and our mirrorswere contacted by thousands of clients, even including military andgovernment computers!

Since there is so little verification of who owns and runs a mirror, there is no guarantee that the mirror is benevolent.Theymay, in fact, be talking to an attacker who has setup a mirror andbecome listed as an official mirror for the distribution.

Some distributions do simple checking that the mirrors respondwith updated and valid content. However, such checks only serve todiscover benevolent mirrors that have fallen behind. They are unable todetect a maliciously operated mirror. Attackers can respond to thedistribution's queries with the expected answer while at the same timetargeting the public at large or individual clients with differentresponses. These targeted responses can include old signed files ormanipulated unsigned files.

Impact: What Can an Attacker Do With a Replay Attack?

Vulnerable Package Installation

When a user installs a package, their package manager retrieves froma repository mirror the list of available packages. A malicious mirrorcan respond to the client with an outdated signed list of packages oran arbitrary list of outdated packages, depending on characteristics ofthe package manager (described in theFAQ).Theclient only knows that files it receives are properly signed by theirdistribution. They do not know that what they have received is an oldlist of packages.

Due to the way existing package managers are currentlyimplemented, it is even possible to provide a client an older list offiles than a list they have already seen. That is, if a client alreadyobtained an updated, signed list of packages yesterday but they aretalking to a malicious mirror today, the malicious mirror can providethe client a signed list of packages from the year before. Themalicious mirror needs only to have a copy of signed files that weremade available by the distribution.They do not need to have compromised the signing key.

Preventing Security Updates

A malicious mirror doesn't have to provide a client outdatedpackages with vulnerabilities known to the attacker in order to leavethe client vulnerable. All that an attacker needs to do is tocontinuously serve the client the same repository metadata. Over time,even though vulnerabilities become known in various packages and newversions become available, the client will never see them whenupdating.

For example, it is known that an earlier version of OpenSSLfor Debian has a security flaw. The list of files from the repositorythat previously included this package is still correctly signed. Usingthis old signed file list, a malicious mirror can keep a client on theinsecure version of OpenSSL by responding to the client's packagemanager with the old list of files.

Protecting Yourself

Things You Can Do Today:

• Use repositories you trust.Use only mirrors thatbelong to reputable organizations. Don't randomly choose mirrors, evenfrom official lists. The official lists of public repositories oftencontain many superficially verified mirrors.
• Manually update your systems (and local mirror caches).Know when package updates become available and what the versions shouldbe. Manually verify and install the updated packages (or add them toyour local mirror cache that your systems update from) rather thanrelying on automated updates. We have observed mirrors many months outof date for some distributions, so you should check periodically thatyour mirror is being updated.
• Use signed repository metadata.If your package manager or distribution does not yet support signedmetadata but only signed packages, at least require signed packagesuntil signed metadata is supported.
• Use HTTPS for mirror communication.Unfortunately, this is generally only available with paid supportservices (and only protects you against man-in-the-middle attacks, notmalicious mirrors). However, by running a distribution with HTTPSsupport on their mirrors, a man-in-the-middle attacker cannot easilylaunch an attack as though it were a mirror.

In the future:

• Use package managers that sign repository metadata.Unsigned repository metadata gives malicious partiesmore leverage in their attacks.
• Use package managers that implement metadata expiration.If there is no way in a package manager for metadata to ever expire, replay attacks will be able to go unnoticed.
• Use distributions that properly make use of the package manager's security features.If a distribution doesn't sign repository metadata or expire thesesigned files even though the package manager supports doing so, itdoesn't help you stay secure.

People

Justin Cappos,Justin Samuel,Scott Baker,John H. Hartman.

Contact us at:or if you prefer want to use GPG, contactusing the GPG key withgpg key fingerprint: 66EF 84E2 F184 B140 712B 55A7 2B96 AB8F DDF1 F3EEathttps://www.cs.arizona.edu/~jsamuel/

Acknowledgments

We would like to thank Ryan Giobbi and the CERT Coordination Center for contacting many of the major package managers and distributions.We appreciate James Hamilton ofOffshoot Inc.creating the logoat the top of this page.We also appreciate the comments given to us by Ryan Giobbi, Igor Crk,Michael Piatek, Angelos Stavrou, Chris Gniady, Yoshi Kohno, and Wenjun Hu.

Other Attacks

In addition to replay attacks, several other attacks on package managers have been identified. Several popular package managers are vulnerable to an attacker who streams an endless quantity of data to them (anEndless Dataattack). Package managers that sign packages instead of the repository metadata are vulnerableto a number of metadata-based attacks includingExtraneous Dependencies,Unsatisfiable Dependencies, andProvides Everything.

Endless Data Attack

In an endless data attack, an attacker returns an endless stream of data to the client whenever files are requested (as previously described inother work).

Most package managers do not properly handle this type of attack. The packagemanagers YUM and APT are used as examples to illustrate the problem, howeverthis problem is not limited to YUM and APT.

When YUM is given a repository metadata file (repomd.xml) file of unlimited size, it exits silently after the filesystem is full with a 1 exitcode --- leaving the huge file on disk. Since no information is logged or printed about the error, this may make discovering the problem complicated (especially if YUM runs via auto-update).

APT is also vulnerable to this attack, but the size of the retrievedfile is assumed to fit in a C unsigned long. This means that APT willwillingly download up to 4 GB of data on 32 bit architectures for eachfile. If APT is compiled on a 64 bit architecture, then it will happilytry to download files greater than 18,000,000 TB! Interestingly, APTcould protect against this type of attack since the repository metadatais signed, known in advance to be small size, and provides the datasizes of the packages and other files to be downloaded.

The endless data attack prevents clients from getting package updates from other repositories. However, this attack also consumes large amounts of disk space on the client system as well as network bandwidth and CPU. Exhausting resources, especially disk space, on a client machine can have disastrouseffects. For example, on Fedora and Ubuntu this prevents logging, corrupts databases, and halts mail delivery.

How can I protect myself against this attack?

The effectiveness of this attack may be mitigated by using a separate filesystem for the cache directory used by the package manager. However, in some cases this attack also results in memory exhaustion (which is notsolved by having a separate partition). It is worth noting that even if mitigation is successful, this attack still prevents updates from other package repositories from being installed.

Extraneous Dependencies

This attack only works on package managers that do not sign repository metadata.This attack is launched by providing false dependency information for a packagethe user will install. The false information says that one package also dependson another that it actually doesn't depend on.For example, an attacker can say that every package depends on some extraneous package of their choice.

This attack works on most modern package managers that do not sign repositorymetadata. Surprisingly, they do not verify that the dependencies in the metadata of thesignedpackages they download match theunsignedpackage metadata they retrieve from therepository! The only restriction in the choice of extraneous package is that if package signatures are checked, then the extraneous package the attacker wants the client to install needs to be correctly signed.Even when signatures are used, this attack can result in new,vulnerable packages being installed.

Another way to use extraneous dependencies is to return package metadata that makes it look like a requested package has a huge number of package dependencies. In most package managers, all of these packages will be downloaded before any signatures are checked.

In addition to consuming disk and network resources on the client, thisattack can be used by a malicious repository to launch an attack onother repositories. The malicious repository can advertise a newversion of a package that depends on the entire set of coredistribution packages, none of which are hosted by the maliciousrepository.Assuming the client is configured to use multiple repositories, it willdownload all the distribution's packages from the other repositories.

How can I protect myself against this attack?

The easiest way is to use a package manager that signs the repository metadata(like APT or YaST). You could also manually do dependency resolution andcheck signatures at the appropriate time, but that largely defeats the purposeof having a package manager.

Unsatisfiable Dependencies

This attack only works on package managers that do not sign repository metadata.An attacker can prevent installation of a package by returning metadata whichsays the package has a dependency on a package that does not exist.This prevents package managers from installingthe package, while to the user it appears that the repository or packager was in error rather than it being a suspected attack.

Note that the attacker need not be able to correctly sign the package of interest. Since packages are not downloaded until after dependency resolution, the client will not download the package (or check the signature).

How can I protect myself against this attack?

The easiest way is to use a package manager that signs the repository metadata(like APT or YaST). You could also download the package and tell your packagemanager to install the local copy. Your package manager will check the signature and use the dependency information from the local copy.

Provides Everything

This attack only works on package managers that do not sign repository metadata.Details of this attack are deferred tothis paper.However, the result of this attack is that an attacker can cause a packageof their choice to be installed when it is unneeded by indicating it resolves dependencies in other packages. This attack allows an attacker tocause a malicious package on their repository to be installed when certain packages on other repositories are installed.

How can I protect myself against this attack?

Once again, using a package manager that signs the repository metadata(like APT or YaST) solves this issue.