On Mon, 2012-10-15 at 13:46 -0400, Michael Gilbert wrote: > Are there bug reports with a clear description of the problem, > preferably with a proposed fix? Discussion doesn't really get us > anywhere. Useful info and actual efforts at fixing problems do. Well it's not that easy in that areas to write simple small issues, when you look back at the discussions from then you probably see why. In small excerpts and short: The most simple form of attacking someone is by using security issues that are know (e.g. because they were fixed in recent versions). So one attack vector would be to prevent that your target doesn't get these updates (which is why they're called blocking). That may e.g. be done by people being in the middle of your line, or having control over your mirror. What do users typically do to stay current? Either they manually update, or they have an auto-update program, or e.g. a Nagios/Icinga check like check_apt. All of this critically depends on the most recent repository data being available. Few isolated issues I found that could now lead to security issues: 1) Programs (I usually mean apt or aptitude here don't give exit statuses != 0 in all cases when something critical has happened. e.g. apt-get update returns 0 even if the update failed. E.g. a cluster operator may have done the following: Added a cron job that calls apt-get update daily and reports an error if $? != 0. Run check_apt via Nagios/Icinga to be notified on updates. An attacker simply blocking the update as described above may now easily prevent updates from being installed. 2) downgrade attacks These have the same idea as blocking attacks (prevent the user to get updates) but are a bit smarter. You don't simply block any update requests, but rather you sent the user old repository data. These are correctly signed by Debian... just... they are old and do not yet know about the updates. The only way of preventing this was, if apt/aptitude would utterly bail out/print error messages/give non-zero exit statuses if the repo-data they are working on are older than <some well thought time interval> (typically that would be something around the mirror update interval). Of course the time of a Release file would have to be signed ;) And of course it would be the duty of a user to make sure he has a correct time source. But at least now he'd have a chance to have a fully secured chain. 3) There were some other potential issues... where I just suspected that things could be problematic... but where I didn't know how to exactly check this. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature