Courtesy of Don Kaminsky's slides for his Black Hat DNS talk, I wound up reading Attacks on Package Managers, which identifies a number of attacks that can be mounted if you can set yourself up as a package repository mirror for your favorite Linux distribution. A number of the attacks are straightforward, but judging from the Slashdot discussion the dangers of unsigned repository metadata are not as clear. So here is an attempt to explain them simply.

Suppose that you are an attacker with a repository mirror (the paper shows that this is not a challenge), and further suppose that there is a package, call it 'frobnitz', that has a security hole that you can exploit (this too is rarely a challenge). Unfortunately (for you) it is an uncommon package that's only rarely installed (perhaps it is an obscure browser plugin for some weird format such as VRML). Your goal is to force frobnitz to be installed on as many machines as possible so that you can exploit it.

With unsigned repository metadata and an uncautious package manager, you have two approaches:

• for every newly updated package that gets added to the repository, edit its dependency information in the repository metadata to claim that the new version now depends on frobnitz. Many package managers will then download and install frobnitz as part of updating the other packages without noticing that the repository dependency metadata disagrees with the actual (signed) package metadata.

• generate a version of the repository metadata that claims that frobnitz provides a huge number of things (especially virtual packages and dependencies), and then take steps to insure that frobnitz will be the preferred thing to satisfy any of these dependencies (possible for many package managers). This will cause many people who install a new package to pick up frobnitz in the process, although the overall install may be broken (since the actual thing they need isn't there, as you fooled the package manager into installing frobnitz instead).

Both of these attacks work fine with signed packages (as do all of the attacks in the paper), and they will also work if only some version of frobnitz is vulnerable, since you can always make that the current version in your repository metadata.

(If you have to use an old version of frobnitz you have only a limited time window to exploit the vulnerability; sooner or later the user's system will contact an honest mirror and fetch a fixed version of frobnitz. Of course, this is where Kaminsky's DNS exploit can come into the picture.)

The good news is that even without signed repository metadata, both attacks can be prevented by a cautious package manager that re-checks dependency and provides information against the actual downloaded packages. (I suspect that a number of package managers will be getting updates soon, since making package managers cautious is a lot easier than changing your repository metadata format.)