| 2008-07-11 01:46:38 |
Till Ulen |
bug |
|
|
added bug |
| 2008-07-11 01:47:06 |
Till Ulen |
bug |
|
|
assigned to aptitude (Ubuntu) |
| 2008-07-11 01:47:19 |
Till Ulen |
bug |
|
|
assigned to synaptic (Ubuntu) |
| 2008-07-11 01:50:16 |
Till Ulen |
description |
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 outdated packages lists which are correctly signed. 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 attacks, 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. That 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 |
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 |
|
| 2008-08-23 02:09:45 |
Till Ulen |
bug |
|
|
assigned to debian |
| 2008-08-23 03:43:34 |
Bug Watch Updater |
None: status |
Unknown |
New |
|
| 2008-10-03 10:51:56 |
Colin Watson |
bug |
|
|
added subscriber James Troup |
| 2008-10-03 10:53:12 |
Colin Watson |
apt: status |
New |
Triaged |
|
| 2008-10-03 10:53:12 |
Colin Watson |
apt: importance |
Undecided |
High |
|
| 2008-10-03 10:53:12 |
Colin Watson |
apt: statusexplanation |
|
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? |
|
| 2009-01-24 01:04:00 |
Kees Cook |
aptitude: status |
New |
Triaged |
|
| 2009-01-24 01:04:00 |
Kees Cook |
aptitude: statusexplanation |
|
|
|
| 2009-01-24 01:04:18 |
Kees Cook |
synaptic: status |
New |
Triaged |
|
| 2009-01-24 01:04:18 |
Kees Cook |
synaptic: statusexplanation |
|
|
|
| 2009-04-09 08:44:41 |
Till Ulen |
removed subscriber Alexander Konovalenko |
|
|
|
| 2011-04-13 10:31:26 |
Julian Andres Klode |
apt (Ubuntu): status |
Triaged |
Fix Released |
|
| 2011-04-13 10:33:06 |
Julian Andres Klode |
synaptic (Ubuntu): status |
Triaged |
Fix Released |
|
| 2011-04-13 10:33:15 |
Julian Andres Klode |
aptitude (Ubuntu): status |
Triaged |
Fix Released |
|
| 2011-08-11 07:43:21 |
Bug Watch Updater |
debian: status |
New |
Fix Released |
|
