Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On 19 October 2012 09:19, Christoph Anton Mitterer
<calestyo@scientia.net> wrote:
> 1) Programs (I usually mean apt or aptitude here don't give exit
> statuses != 0 in all cases when something critical has happened.
The apt-utils are mostly ok at aborting with non-zero for critical
errors. Aptitude is not.
> e.g. apt-get update returns 0 even if the update failed.
This is only for transient errors (such as connection problems)
printed with a “W:” label. If a Release file is expired or otherwise
invalid the exit status is reliably non-zero.
After Wheezy it may be useful to look at using $? = 1 (or 2) to
indicate these transient errors (or just consider them the same as the
other errors). Calling programs could then retry the update, or
switch to a different mirror, which may resolve the issue. If the
calling program doesn't care it can test for $? != 0 to catch *all*
errors, or $? = 100 for only serious errors.
>
> 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.
For a short time. Eventually “update” will (or should!) complain
about the expired Release files, $? != 0.
> 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.
Security and -updates Release files use Valid-Until which partially
addresses this. I think this will only trigger an error on “apt-get
update”, not “install” or “upgrade”. Presumably update scripts use
“update” before “upgrade” and check the status of the former.
Reply to: