The following packages cannot be authenticated

[Colin Watson]

On Fri, Dec 02, 2011 at 11:09:22AM +0200, Marius Gedminas wrote:
> On Wed, Nov 30, 2011 at 08:53:41AM -0600, sktsee wrote:
> > On 11/30/2011 04:57 AM, Shawn Pringle wrote:
> > >Before installing samba, I received this warning:
> > >
> > >"The following packages cannot be authenticated!"  I didn't know there
> > >was any kind of certificate system in place.  Can someone tell me what
> > >this means exactly, how serious is the risk and why common are
> > >packages that can be authenticated?
> > 
> > That usually means that you need to run "sudo apt-get update" before
> > installing your package so that apt can authenticate the repo.
> 
> Incidentally, why does it happen?  An intermittent network connection
> that didn't let the previous apt-get update download the right
> Release.gpg?  An archive update that coincided with your apt-get update,
> and so you downloaded a Packages.gz that is newer than your Release
> file?

If 'sudo apt-get update' still returns an error, it's possible that
you're running into this bug, especially if you're behind a proxy:

  https://bugs.launchpad.net/ubuntu/+source/apt/+bug/24061

If so, 'sudo rm /var/lib/apt/lists/*Release' and try again.

It's also possible that you or the mirror you're using got unlucky and
downloaded mismatched versions of the Release and Release.gpg files.
This can happen sometimes, and the remedy is usually to wait for a while
until the mirror updates again and re-run 'sudo apt-get update'.  The
fact that this is possible, because the index file and its signature are
in separate files, is a known bug in our archive.  Unfortunately, fixing
this bug would permit exploiting a security vulnerability in Ubuntu
11.04 as released, so we can't fix this until either Ubuntu 11.04 is no
longer supported or we switch to a new archive signing key:

  https://bugs.launchpad.net/launchpad/+bug/804252

(Of course, it shouldn't be ruled out that somebody is actually
attempting an attack; that's what the system is there to defend against,
after all!  I wouldn't panic and jump to that conclusion first, though.)

> > The following link explains the process of how APT authenticates
> > repositories and checks package integrity.
> > 
> > http://wiki.debian.org/SecureApt
> 
> I see my question is also raised (but not answered) in that FAQ:
> 
> } Another problem you may encounter if using testing or unstable is that
> } if you have not run apt-get update lately and apt-get install a package,
> } apt might complain that it cannot be authenticated (why does it do
> } this?). apt-get update will fix this.

There is a category of attack, called a "replay attack", that works
roughly like this:

 * Take a snapshot of the archive index files.

 * Interpose yourself between the archive and the machine you're trying
   to attack, by way of an evil web proxy or packet interception or
   similar.

 * Any time the victim machine tries to update from the archive, reply
   with the snapshot you took of the index files.

 * Wait until an exploitable security update is published.  Since you've
   frozen the victim's machine at a snapshot, they'll never see that
   update, and you can attack them at your leisure.

To mitigate this, apt has a feature whereby an archive can declare its
index files as only being valid for a certain amount of time.  This
means that if you try to replay a snapshot older than this then apt will
not consider it authentic.

However, Debian is ahead of us on this.  The Ubuntu archive does not yet
implement this feature:

  https://bugs.launchpad.net/launchpad/+bug/716535

I've been doing some hacking on the Launchpad archive publisher lately,
so I think I might have a go at fixing this soon.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]