Package managers vulnerable to replay and endless data attacks

[Till Ulen]

Binary package hint: apt

apt and possibly other Ubuntu package managers capable of downloading packages are vulnerable to two kinds of attacks.

1. Replay attack, where an attacker, by operating a malicious mirror or by spoofing the address of a valid mirror, serves correctly signed but outdated packages lists. As new vulnerabilities are discovered and patched, the users who are using the malicious mirror won't be receiving any updates and will continue running vulnerable software.
See http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html

2. Endless data attack, where an attacker serves very long files to a package manager that uses his malicious mirror. That might prevent the package manager from ever completing, leading to the same problem as described above. It might also consume all disk space preventing logging, mail delivery and other system services from running properly.
See http://www.cs.arizona.edu/people/justin/packagemanagersecurity/otherattacks.html#endlessdata

There is also an entry on Ubuntu and Debian in the FAQ at http://www.cs.arizona.edu/people/justin/packagemanagersecurity/faq.html

[Till Ulen (tillulen)]

See also this post in the CERT vulnerability analysis blog: http://www.cert.org/blogs/vuls/2008/07/using_package_managers.html
They have assigned a vulnerability number to this issue (VU#230187) but it doesn't seem to be public yet.

[Colin Watson (cjwatson)]

So, I agree with this bug, although I think that it is primarily relevant to security.ubuntu.com. The main release pocket doesn't change after release anyway, and I think most people running development releases will get itchy if there are no updates for several days (they certainly seem to during freezes!). Attaching this condition makes it easier to fix this bug, because we direct all Ubuntu users to security.ubuntu.com rather than to mirrors, so this means we don't have to worry about how to balance rapid notification of risk against slow mirror update frequencies. (We don't want to issue incorrect security warnings any more than we want to fail to notify users of attacks.)

I had a discussion with James Troup (who runs our system administration team) and we agreed that we should do the following:

"
 a) regenerate the -security Release files at least twice a day
 b) modify apt to freak out if a -security Release file is > 1 day old (this should probably be a configuration option so that the trip point is configurable but also we only want to trigger on security.ubuntu.com, not a mirror.)

This closes off the 'MITM with a stale archive' avenue of attacks.

The downsides (that I can immediately think of) are:

 a) increased traffic on security.ubuntu.com (fine by me - since the "alternative" is https ;-)

 b) we _have_ to keep updating security.ubuntu.com. We can't have the publisher cron jobs down for more than a day (? possibly less) or so without making millions of users freak out.
"

I therefore suggest that apt should grow a configuration option to set a per-host maximum age for mirror files, which is checked on update. There's already APT::Acquire::mirror::MaxAge, which suggests the obvious extension APT::Acquire::mirror::security.ubuntu.com::MaxAge. Could we arrange for a desktop notification when this age is exceeded, if there isn't one already?

Of course, this needs to be checked only on update (the user simply not bothering to run 'apt-get update' doesn't correspond to a stale-archive attack). We should also consider what to do about transient network failures: on the one hand, we don't want to claim that an attack is in progress when the user simply didn't bother to connect to the network for a couple of weeks; on the other hand, the simplest stale-data attack for an evil ISP is simply to null-route security.ubuntu.com. What do people think?

[Jamie Strandboge (jdstrand)]

IIUC, there are two errors we can check for and report: network failure and stale data. Eg, if we don't have a network failue, but we do have stale data, then give the severe message. If you do have a network failure/hiccup, report something less severe instead, possibly with an option for opting out of network failure warnings.

Another option is appropriate wording that says something like "Apt has detected stale data after performing an update of its cache. This could be the result of a transient network failure or an indication of a man-in-the-middle attack..." Of course, that is suboptimal if it happens *every time* there is a network hiccup.

[Julian Andres Klode (juliank)]

Release files can expire now, so part 1 is done. Part 2 can't be done at all, as the definition of long is relative.