[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[RFH] The need for signed packages and signed Releases (long, long)



Please bear with me, this issue has been discussed before (both in the
debian-security mailing list and here). The current state is also well
documented [1] (but far from perfect). I'm asking here for help
so that other developers can help solve this issue (see below why).
Anthony Towns and the other ftp-maintainers will probably need help to
setup the proper infraestructure.

The needs are:

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 (as Jason commented in his RFH) and not through a script which is the
current only way (see the documentation link below). I will file a bug
soon (since I do not see it filed yet)

2.- we need to have all the packages in the archive signed so that users
can download them individually and check signatures. Currently the PGP/GPG
signature is removed when a developer uploads (is the .deb package signed
at all?)

Aj prefers 1) over 2) but I'll explain why 2) is also needed (for 1) refer
to documentation and help patch 'apt'). 

[start long-story]

I listened to a conference that I had in mp3 from the
Madrid Hackmeeting [2] 2002 regarding "Assembler viruses". As a matter of
fact the conference took place after my own ("Security in the Debian
GNU/Linux OS"). 

The scary thing about the virus conference it how it detailed that the new
virus attacks might use the package management architecture to infect the
system. Yes, you can do so much if you are running as a single user and
get infected. But what can happen if a virus installs itself in package
files you have downloaded for installation (a per-process virus could do
this by infecting your web-browser, for example). Once the package
installation is called the virus can do whatever he wants to (as root)
making using of tampered postinst/preinst scripts. The person that gave
the conference thought that this was the way that viruses were going to be
distributed for Linux in the near future (and he might even be right).

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). 

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.
[end long-story]

Regading 1)  (correct me if I'm wrong): Debian does not (I'm not sure if
Progeny did) provide .deb signed packages in a manner which will be
checked by 'dpkg' when installing the package. Also, user's/developers are
staring to offer unsigned unofficial packages on websites. The only way to
provide our users a secure method (automatic and easy) to prevent a trojan
from distributing itself through these, is to have package signatures.
It's a feature not only for the Debian mirror (when a user downloads a
single package and does not use 'apt') it's a feature to all those
providing unofficial packages out there (even developers).

There are currently some ways to exploit this issue. An example is
spoofing DNS records and have a trojaned archive for security.debian.org.
Users downloading *only* from security.debian.org who do not **manually**
check the MD5sums of the packages, check the signatures of the DSAs and
then install the packages are open to attack.  Note that most user's just
have some automatic method of updating from security.debian.org (it's even
encouraged [3]). In Desktop systems (such as the ones that the
Debian-Desktop proyect, LinEx or others are trying to make) the 'check for
security updates' might be just a button in the desktop which turns red
whenever there is one and the user just clicks it and enter's root
password. 

Currently debsig-verify is not useful without provided policies (which it
currently does not and so bugs like #161162 get filed). OtoH there's not
even a README that describes how to set debsig-verify up! (More
documentation here is needed)

How should we proceed here? (note that we have already started thanks 
to the excellent work of Aj, Wichert and other DDs. They, however
probably would appreciate a hand to get this finished). 
IMHO:

- sign the packages in the package archive (IIRC only the Release file is
signed)

- accept signatures in packages when uploading to the archive.

- have dpkg-buildpackage et al sign packages (I believe they sign the .dsc
and .changes files, not the package themselves) and do not remove the
signatures when they get uploaded to the archive

- distribute debsig-verify with a standard policy don't accept anything
that is not signed by a Debian developer (user's can customize this
further on if they want it)

In order to sign the whole archive probably we should start by fixing Bug
#112824 (and use it to sign all of it by someone "very trusted") and then
start accepting package signatures for new uploads. Dpkg-buildpackage
might need to be fixed since it currently signs .dsc and .changes files
but *not* the .deb package itself.

IMHO we're beind rpm here, and this should be fixed for the next major
release [4]. At the very least, we are not providing enough information on
how to do this (since I, at least, I'm not aware of it :)

Of course this should be done, let's not hit stones other's have hitten
before [5] and use other's insights on the matter [6] not only our own
ideas and opinions (I include myself here :)

Regards

Javier Fernandez-Sanguino

PS: I'm pretty sure many think this is a horse beaten to death but I've
you've get this far, thanks for listening :)


[1] In the "Securing Debian Manual" (although it might be a little bit
out of date)
http://www.debian.org/doc/manuals/securing-debian-howto/ch7.en.html#s-deb-pack-sign

[2] http://www.sindominio.net/madhack02/
[3] In the "Securing Debian Manual" (and yes, it might be my fault):
http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s-keep-up-to-date
[4] http://online.securityfocus.com/columnists/48
[5] http://online.securityfocus.com/bid/5594
[6] http://www.cryptnet.net/fdp/crypto/strong_distro.html

Attachment: pgpCjh3ErP29P.pgp
Description: PGP signature


Reply to: