[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

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

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.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: