Re: Revocation list for old packages with security holes (was: Re: Revival of the signed debs discussion)
"Julian Mehnle" <lists@mehnle.net> writes:
> Joey Hess <joeyh@debian.org> wrote:
> > Goswin von Brederlow wrote:
> > > What can we do with deb signatures?
> > >
> > > For our current problem, the integrity of the debian archive being
> > > questioned, the procedure would be easy and available to every user:
> > >
> > > 1. get any clean Debian keyring (or just the key signing the keyring)
> > > 2. verify the latest Debian keyring
> > > 3. verify that each deb was signed by a DD and the signature fits
> >
> > The canoical attack against signed debs in this situation is to find a
> > signed deb on snapshot.debian.net that contains a known security hole.
> > Now inject it into the compromised archive, with a changed filename, and
> > edit the Packages file to have its md5sum. Now a user's checks will
Packages contain the control file which has all the informations about
the package. Also apt will not successfully install a deb package with
a changed name.
Signed debs prevent any tampering with the package post signing.
Changing the name or version of the file and in Packages leads to
confusion now and can be easily deteced, if one can trust the control
file within the deb (i.e. if its signed).
The only attack left is compromising a mirror and keeping a newer
(fixed) version out so people will still install an old buggy
version. Ensuring the Release.gpg file is resigned frequently would
allow users to detect when its held back by a compromise. But since
every done something is uploaded Release.gpg will be signed daily
already. Its not 100% reliable but a Release.gpg older then 3 days
would be very suspicious.
> > succeed -- the package is signed with a developer's key -- but they will
> > install the old, insecure .deb. The only hint will be a warning from
> > dpkg that it is downgrading the package, and a clever attacker might
> > avoid even that.
How do you avoid that? You can use a package with a higher version and
rename it but then apt won't work even without checking the control file.
> We could use a revocation list where signatures of packages with
> known security holes are listed as being revoked. Of course, you'd
> need to be online to check it when installing/updating packages.
> And the revocation list would best be served from a server that's
> secure and separate from the archive servers to make attacks against
> it a bit more difficult.
And how do you make sure the revokation list isn't compromised (kept
in the state it was a few days ago)? Its the same problem as with the
Packages/Release.gpg files.
> > I would still like to be able to produce signed debs, it's another layer
> > of security, but they are no panacea.
>
> True.
Signed debs basically add nothing except ease of use and
transparency. All the security that would be contained in a signed
deb is already contained in the changes and Release.gpg. But checking
those changes files is complicated. A signature in the deb would be
equally secure (and equaly insecure) but just so much easier for the
user.
That the one (two) big argument for signed debs: ease of use and
transparency.
MfG
Goswin
Reply to: