Re: heads-up for critical apt problem
On Thu, Sep 22, 2016 at 07:35:22PM +0200, Nico Golde wrote:
> + apt list
>
> Hi,
> * Bjoern Jacke <bjoern@j3e.de> [2016-09-22 15:06]:
> > On 22.09.2016 14:19, Nico Golde wrote:
> > > Wouldn't a person being in charge to apply updates in the first place also
> > > notice this error and fix it?
> >
> > as I have written in the bug report. The error message says explicitly
> > that only that single repository will not work - which generally implies
> > that other repositories will be unaffected.
> >
> > A repository or mirror maintainer (I am one for example...) would be
> > able right now to stop any update to be installed on their users'
> > servers. Users would see a message that my (attacker) repository is
> > "expired" but all the other repos are fine (including
> > security.debian.org!). Then I would have time to hack them. From my
> > server logs I would even see, who of the users did *not* disable my
> > intentionally broken repository.
> >
> > I might also time my attack better: I wait for some upstream project to
> > report a serious remote exploit and THEN break by repository, so that
> > server maintainers don't have much time to notice the error message that
> > they have a broken repository. Users would not receive the updates for
> > the just released security fixes.
> >
> > Now that I pointed out how I might easily prepare attacks with this apt
> > bug it look to me like a very obviously critical security flaw. This
> > looks to me like one of those class of bugs which might have been
> > implemented intentionally. I hope you see this the same way and push the
> > apt maintainers to fix this as soon as possible.
>
> Thanks a lot for your detailed thoughts on this, this definitely helps
> understanding you better. I have tagged the respective bug entry as a security
> bug based on the general understanding and agreeing that this can have
> security impact. I do not agree with regard of your applied rating (which is
> btw not reflected in the BTS) however for two reasons: apt itself is not a
> silver bullet for solving security problems, in the end it's administrators or
> automation behind these tools that needs to do the job; more importantly
> though, your rationale is based on assuming that it's a key aspect to a
> compromise to have more time.
>
> This certainly helps in some situations, but the general rule of thumb is you
> need to apply updates as fast as possible, you should not do this blindly and
> if you do problems likely occur, and even then you can be unlucky as most of
> the fixed issues are not unknown at the time of the fix to the broader public.
>
> This is not meant to shoot you down, I am eager to hear the response of the
> apt maintainers as well. Please stop speculating about the origin of an issue
> as this is not constructive and might also be taken as rude.
>
I consider this a minor issue, if the behavior does not match
the described behavior. APT's primary use case is interactive
use, and it's secondary use case is in cron jobs. In the first
case, the user would immediately be notified of the issue and
can fix it. In the second case, the administrator receives an
email and can act upon it as well (starting with 1.3, they will
receive an entry in their systemd journal, if they use systemd).
The threat model is absurd. If you use apt manually, you'll not
see a security fix before updating. If you update, you will notice
the issue.
If you use unattended-upgrades, the update is performed daily. It
is very likely that the cron/systemd job updates the repository before,
notifying you of the issue via email or journal/syslog (which I
suppose you are monitoring for errors if you care so much about
security).
In any case, there are far more ways to prevent access to an
updated repository.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.
Reply to: