Re: Revocation list for old packages with security holes (was: Re: Revival of the signed debs discussion)
Julian Mehnle [EMAIL PROTECTED] writes: Joey Hess [EMAIL PROTECTED] 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
Re: Revocation list for old packages with security holes (was: Re: Revival of the signed debs discussion)
* Julian Mehnle ([EMAIL PROTECTED]) [031210 13:40]: Joey Hess [EMAIL PROTECTED] 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 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. 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. Yes, that would also be a good enhancement. However, verifying the actual control files of a package again the information in Packages is also worth doing. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
RE: Revocation list for old packages with security holes
Goswin von Brederlow wrote: Julian Mehnle [EMAIL PROTECTED] writes: 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. The revocation list would need to be signed with a special private key that is stored on a non-networked machine. It's not too often that signatures of old packages need to be revoked. Probably mostly just whenever the security team releases a security-fixed package (of course also on some other occasions). Of course, such a package revocation list brings all the problems that other types of revocation lists, e.g. SSL certificate revocation lists, have. But as proven by VeriSign Co., these problems can be successfully mastered. That the one (two) big argument for signed debs: ease of use and transparency. Not exactly. Also, individual signed debs could be downloaded[1] and verified *individually*. No need for Packages/Release.gpg files. [1] E.g. from http://wiki.debian.net/?DebianKDE or http://people.debian.org/~$developer/
Re: Revocation list for old packages with security holes
Julian Mehnle [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: Julian Mehnle [EMAIL PROTECTED] writes: 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. The revocation list would need to be signed with a special private key that is stored on a non-networked machine. It's not too often that signatures of old packages need to be revoked. Probably mostly just whenever the security team releases a security-fixed package (of course also on some other occasions). You completly missed the point. Say something gets revoced, added to the list and the list is signed and all. But still this stupid transparent proxy of my stupid ISP will give last month list and I will never know something got revoked. The same could happen intentionally by an attacker. Of course, such a package revocation list brings all the problems that other types of revocation lists, e.g. SSL certificate revocation lists, have. But as proven by VeriSign Co., these problems can be successfully mastered. That the one (two) big argument for signed debs: ease of use and transparency. Not exactly. Also, individual signed debs could be downloaded[1] and verified *individually*. No need for Packages/Release.gpg files. Yes, you don't need archive the Release.gpg or changes files from the time the package was released: ease of use. You can even verify debian.snapshot.net. MfG Goswin
