Apt vulnerability sparks Debian security discussion

Downloading packages from a distribution's repositories is generally considered to be a safe operation—packages are (or at least should be) signed and those signatures are verified before installation. Debian's Apt package manager has used cryptographic signatures to verify the authenticity of packages for more than ten years. So it was a rather large surprise to see a late May report that Apt doesn't require valid signatures for source packages.

Jakub Wilk found the bug when testing repositories with packages that didn't have any signatures. By using a proxy that returned 404 "not found" errors for any requests targeting Release.gpg or InRelease files (which hold the signatures), he found that installing or downloading binary packages failed (as expected). But he also found that downloading or unpacking a source package worked, as did building a binary package from the downloaded source package. That is clearly a flaw that a man in the middle (MITM) could exploit to put compromised source files onto Debian systems.

It is a difficult vulnerability to exploit, perhaps, and would require user assistance (i.e. building the package) to activate a malicious payload, but it certainly runs afoul of reasonable expectations. One can also imagine targeted attacks using the vulnerability that could be far more destructive. Worse yet, though, is that the normal methods for rebuilding the Debian archive (e.g. for a new architecture) would not detect this kind of tampering, as Thorsten Glaser pointed out. Those methods assume that apt-get source pkg always verifies the signature.

The problem in Apt was fixed quickly. The function that handles source packages simply needed to call the IsTrusted() method to verify the signature. In addition, a test case was added to catch this if the bug ever reappears. The bug was then closed by Michael Vogt on June 10, only to be reopened by Christoph Anton Mitterer two days later.

Although there was mention of contacting the security team in the bug, that evidently never happened. So one of the reasons that Mitterer reopened the issue was to ensure that a CVE got assigned and that a Debian Security Advisory (DSA) was issued. As he put it: "So IMHO this bug definitely deserves a CVE and a DSA,... so that people are informed that [their] systems might have been compromised (i.e. if an attacker tricked them into using forged sources)". A CVE was duly assigned (CVE-2014-0478) and DSA-2958-1 was issued.

But there are a number of larger issues here. Mitterer outlines some of them in his lengthy bug-reopening message. He is concerned that various pieces of Debian infrastructure are insufficiently secure against (mostly) MITM attacks. For example, Apt will work with unsigned repositories, which is seen as a feature by some. As David Kalnischkies said: "The 'problem; is that apt supports unsigned repositories as too many people would bitch too much if it would require a signature – it used to work before apt 0.6, it has to work forever, man – FOR EVER!" Glaser's description of the potential MITM problems with sbuild and cowbuilder also factor in. Beyond those, Mitterer wondered about the security verification in packages that download code from elsewhere (e.g. Tor browser or Flash plugin) and other Debian tools that grab code to be built or to create new systems (e.g. debootstrap).

But there is more to improving the security of Debian (or any project, for that matter) than just compiling lists of problem areas. As security team member Thijs Kinkhorst pointed out in a post to the debian-devel mailing list—where parts of the discussion moved—finding some piece of the problem to work on may be a better approach:

Kalnischkies had a similar comment:

But there certainly is value in collecting up problem areas and trying to figure what the "proper" solution should be, Mitterer argued. Because many of the solutions would require fairly major changes to how things are done and what types of behavior are allowed—policy decisions, essentially—they are not things that Mitterer (or any single developer) can directly address without involving others.

It's clear that there are some holes in Debian's packaging infrastructure. Beyond the bug that Wilk just found, he also encountered a bug that was reported over a year ago regarding the hash checking done for source packages. It turns out that Apt only checks the MD5 hash, even if there are SHA1 or SHA256 hashes available for the package. That seems rather sloppy, even though it may be hard or impossible to exploit—as Kalnischkies put it: "If you happen to have a same-size preimage attack on MD5 I would be interested to hear about it."

Mitterer is trying to raise the profile of these problems—with many lengthy replies throughout the bug and mailing list threads—but there is little evidence that much progress has been made. Some of the problems may be less dangerous or harder to exploit than Mitterer makes them out to be, but they add up to something that should be a bit worrisome. The inertia of a long-running project may be working against some kind of concerted effort to address the problems, as "we've always done it that way" can sometimes be a powerful, if potentially problematic, argument. It will be interesting to see what, if any, attention these problems get over time—it may require someone to drive the process with more than just ideas and words.