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?
** Changed in: apt (Ubuntu)
Importance: Undecided => High
Status: New => Triaged
--
Package managers vulnerable to replay and endless data attacks
https://bugs.launchpad.net/bugs/247445
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
