On Tue, Nov 12, 2002 at 03:37:11PM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> 1.- we need the means to check releases in a secure way for installation
> through remote (web, ftp, nfs) or local media. This needs to be done by
> apt [...]
>
> 2.- we need to have all the packages in the archive signed so that users
> can download them individually and check signatures. [...]
>
> Aj prefers 1) over 2) but I'll explain why 2) is also needed (for 1) refer
> to documentation and help patch 'apt').
I'm not sure why people seem to think the story begins and ends at what I
prefer. It doesn't. (1) is effective and feasible with Debian, (2) is not.
> This can *only* be avoided by signing packages and checking signatures on
> installation (note that Relase signing is not feasible here since we are
> going to use 'dpkg' and not 'apt' to install the package once downloaded).
Then don't do that: verify every package you download as soon as you
download it, and don't install any packages you couldn't verify.
> We might be aware of the problems but, the fact is, Debian is still open
> to this kinds of attacks until we take a stand to fix it.
Unless you use the script that's been around since January. Or write a patch
to apt to incorporate that functionality into it.
> Regading 1) (correct me if I'm wrong): Debian does not (I'm not sure if
> Progeny did) provide .deb signed packages
Progeny did, and they did it in a way that was both effective and
infeasible for Debian to duplicate. (You presumably meant "Regarding 2")
> - sign the packages in the package archive (IIRC only the Release file is
> signed)
The dists/<foo>/Release file has a detached signature
dists/<foo>/Release.gpg; the Release file contains the size, md5sum and
sha1 checksum of all the Sources and Packages files; the Sources and
Packages files in turn contain the size and md5sum of all the debs and
sources you might wish to download.
> IMHO we're beind rpm here, and this should be fixed for the next major
> release [4].
You could say the same thing in that dpkg doesn't support file
dependencies. Looking at features without their larger effects is
pointless.
> PS: I'm pretty sure many think this is a horse beaten to death [...]
Quite.
The problem with signed debs within Debian is that they don't give you
any information. They can indicate that J. Random Developer produced the
package. They can't tell you if that package came from unstable, testing,
stable, oldstable, from archive.debian.org, or from some random site
the maintainer uses for random hacking -- unlike Progeny and Red Hat we
can't simply change every package we distribute when we make a release,
since it'd kill our mirrors. They could tell you the package came from
Debian, although doing so would mean the deb we distribute would have
a different md5sum to that in the .changes, and would be different to
the .deb you uploaded.
Knowing the .deb is from some particular developer doesn't buy you
much. It can even be confusing: should you trust a package built by
someone who's not a member of the project any more -- what if they
retired due to lack of time? what if they were expelled due to trojaning
packages? if the answers are different, how do you tell the difference?
How about a stable update by someone who joined the project after
stable (and the debian-keyring it shipped with) was released? How do
you ensure that key revocations and other updates make it to you? What
are the potential risks if someone compromises one of the keys -- how
will it be discovered if, rather than uploading the trojan signed by
"Bdale Garbee" to the archive for many eyes to notice, it gets put on a
single underused mirror that happens to be used only by the particular
target of an attacker?
Even if you know with absolute _certainty_ that I, personally, built
the .deb you're installing, this doesn't tell you all that much --
I've released packages with security holes, and nasty bugs. They're not
deliberate trojans, but that doesn't mean they couldn't be deliberately
used in that way. You don't have a huge amount of control here, but the
potential problem is pretty bad: all you need to do is take control of
a mirror used by your target, find a newer version of a package used by
your target that has a security hole (which may well be fixed by now),
and put that in your target's Packages file for his next upgrade. If
you're unlucky, he might notice that the new version doesn't seem quite
like what he should be getting, but you can minimise that risk by reducing
the number of people who get your trojaned Packages file, and by blocking
your target's access to security.debian.org and debian-security-announce,
and so on. It's not necessarily exploitable, but then, neither is a
double free() bug.
The problem here is that since you can't update the signatures attached
to a .deb (since that would force mirrors to redownload the entire archive
semi-regularly, and would then force user's to do likewise for no benefit
to them) you can only have a signature on the .deb from before you've
run it through the usual means Debian has to ensure its releases are
secure. Looking at such a signature, you can't tell if it's been in
unstable for very long and if any bugs were found, you can't tell if
the security team have had to issue advisories about it, and so on.
If you really want to avoid the risk of people trojaning your mirrors
and feeding you something other than prime-grade Debian, you need to go
all the way -- validate your Packages files, ensure that you're getting
packages from the same release of stable, testing or unstable, ensure
that you're not getting packages from unstable when you want packages
from testing, check that your security tree is getting too long in the
tooth, *everything*.
And Release signatures actually _do_ this, without imposing any particular
stress on the system at all -- no debs have to be updated and there's
no extra churn on the mirrors or on users systems.
It's a valid complaint that {Release,Release.gpg,Packages.bz2} is a
lot of stuff to download just to verify a single .deb. It's also one
that's easily fixed in a lot of ways other than providing signatures on
the .debs. One solution is to keep around all the signed .changes files
that the debs were uploaded with, and make it easy to find the right one
for any given .deb you might want to use. Another is to have a server
somewhere that you feel is reliable, which you will find the details of
a deb given a local copy of Release/Release.gpg/Packages.bz2 and give
you signed output that lists nothing more than the size and checksums
of the deb you requested.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``If you don't do it now, you'll be one year older when you do.''
Attachment:
pgpwsXBs9MBW3.pgp
Description: PGP signature