Software Deployment Security:
Attacks on Package Managers and their Mitigation
Georgios Giantamidis
Abstract—Software deployment on Linux relies on package
managers and package repositories, due to the tedious and
sometime complex work required to install, upgrade, configure
and remove software in a consistent manner. Several security
problems can arise in this setting that range from simply crashing
a client’s machine to even installing an arbitrary malicious
package on it. The conditions that enable each problem to
manifest are examined. Countermeasures to each problem in the
package manager and overall deployment architecture levels are
also presented. We conclude that it is possible to reach a relatively
high level of security without sacrificing convenience, but a
coordinated effort of package manager developers, repository
administrators, software developers and end users is required to
achieve this.
of security based on where in the deployment pipeline there
is use of cryptographic signatures. The list of attacks and
their descriptions are also presented here. Section 4 focuses on
countermeasures. Fixes on package managers, on the overall
deployment scheme as well as best practices for end users are
proposed. Section 5 summarizes the results and suggests some
ideas to be explored.
II. S OFTWARE D EPLOYMENT OVERVIEW
A. Package Managers
*
we distinguish between package installers and
dependency resolvers
*
package installers like dpkg [2] and rpm [4] are low
level tools, usually tied to a specific package format
*
package installers unpack package files to
appropriate location, track installed packages
using a database, remove and update packages
*
dependency resolvers like apt [1] and yum [3] are
front ends to package installers
*
dependency resolvers download the requested package as well as other packages needed to install the
requested package
I. I NTRODUCTION
Installing, upgrading, configuring and removing software
from a system in a consistent manner can be a daunting
task. Apart from the potentially big volume of files one has
to face when dealing with a single piece of software, there
is also the issue of dependency resolution. That is, in order
to install a piece of software, something else may need to
be installed first. Manually doing all this work can be very
tedious and sometimes even practically impossible. This was
the reason package managers were invented. They automate
the procedures mentioned above, making sure they always
leave the system in a consistent state. Package managers
retrieve the various pieces of software in the form of packages
from package repositories. It is common in the Linux world
that a distribution has several public mirrors of their software
repository and practically anyone within a matter of days or
even hours can setup their own official public mirror of one of
the major Linux distributions. This setting gives rise to several
security problems that can ultimately make a client install an
arbitrary malicious package, install an old version of a package
with known vulnerabilities, render the client unable to update
a vulnerable package to the latest version, or simply consume
resources of the client’s machine and potentially crash it
and / or corrupt data stored on it. Not all distributions are
vulnerable to every problem mentioned above. Differences in
their software deployment architecture and package managers
make them secure against some problems and vulnerable to
others. Furthermore, it is even possible through careful design
of the deployment scheme and patching of package managers
to achieve a relatively high level of security. The next section
presents an overview of the software deployment mechanism.
The package manager, package and software repository concepts are presented and discussed. Section 3 introduces levels
B. Packages
*
packages are archives containing application specific
files as well as additional metadata
*
package metadata contains information about what
the package provides and what it depends on
*
some package formats (e.g. rpm) also have space
for a digital signature
*
popular package formats : .deb [5], .rpm [6]
C. Repositories
*
repositories are http(s) / ftp servers that store
packages, package metadata and the root metadata
file
*
repository root metadata contains the location and
secure hashes for package metadata tarballs
*
often there are multiple official mirrors of the main
repository
*
(repository structure image here)
C. Best user practices
*
use only trusted repositories
*
update manually, not automatically
*
use https if possible to protect against MITM attacks
*
use package managers that sign repository metadata
*
use package managers that implement metadata expiration
III. S ECURITY L EVELS AND ATTACKS ON PACKAGE
M ANAGERS [7]–[9]
V. S UMMARY AND F UTURE E XPLORATIONS
A. Security Levels
*
no signatures at all
*
signatures on individual packages
*
signatures on package metadata
*
signatures on root metadata
B. Attacks
*
arbitrary (malicious) package
*
replay attack (client installs old, vulnerable package)
*
freeze attack (client can’t update to new package)
*
extraneous dependencies
*
endless data (consumes resources of client’s machine
- may corrupt disk data)
C. which attacks affect each security level?
IV. C OUNTERMEASURES [7]–[9]
A. Fixes on overall architecture
*
use signatures
*
a combination of signatures on root metadata as well
as on individual packages provides a good level of
security and convenience
B. Fixes on package managers
*
package managers should take as much advantage as
possible of the underlying deployment infrastructure
*
e.g. yum did(does?) not verify whether the package
metadata initially received for dependency resolution
matches the embedded metadata of the downloaded
packages, which allows forging package metadata to
launch an extraneous dependencies attack
TODO
R EFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
https://wiki.debian.org/Teams/Apt
https://wiki.debian.org/Teams/Dpkg
http://yum.baseurl.org/
http://rpm.org/
.deb package format : http://linux.die.net/man/5/deb
.rpm package format :
http://www.rpm.org/max-rpm/s1-rpm-file-format-rpm-file-format.html
[7] Justin Cappos, Justin Samuel, Scott Baker, and John H. Hartman. 2008.
A look in the mirror: attacks on package managers. In Proceedings of
the 15th ACM conference on Computer and communications security
(CCS ’08). ACM, New York, NY, USA, 565-574. DOI=http://dx.doi.
org/10.1145/1455770.1455841
[8] https://isis.poly.edu/∼jcappos/papers/cappos pmsec tr08-02.pdf
[9] https://www.usenix.org/legacy/publications/login/2009-02/openpdfs/
samuel.pdf