After the recent stories with the trojaned software on win.tue.nl I realized that while PGP signatures on RPMs allow one to safely upgrade single packages, installing/upgrading the whole distribution does not check PGP signatures and can potentially install trojaned software. There are several security issues assotiated with install/upgrade from an untrusted source (such as ftp/nfs install/upgrade from the ftp.redhat.com mirror), but they all are relatively easy to fix. Problem: Floppy disk images are not PGP-signed. Solution: put PGP signatures for disk images on ftp.redhat.com Problem: Install/upgrade does not check PGP signatures. Solution: Write a program that would check if an RPM is signed with RedHat public key. Since this program does not perform any encryption, its binary should be exportable. Add this program to the installer, add the option to use it, make it turned on by default at least for NFS/FTP installs/upgrades.
We can not ship PGP.
You do not have to ship PGP. You have to write a binary-only program capable of checking pgp signatures. Is not it true that such a program would be exportable?
I don't believe that it would be exportable, but I am not a lawyer. In any case, I truely don't have time to write a signature checking program at the moment.
Now that you are using GPG for signatures, would such signature-checking program make sense?
We have added this request to the "wish list" for future releases.
Is this really fixed?
Jeremy - can you update this bug if it is now fixed?
We currently check the md5 digest of the package. There's a bit of a chicken and the egg problem involved with checking the GPG key as to where the GPG key gets retrieved from.
The kernel and the boot initrd are implicitly trusted anyway, and as long as all images come with a signature (should I file a separate RFE?) we can assume that the kernel and initrd are valid and have a key on initrd. For complete security first stage should also be able to check sig (or md5sum if the correct value is hardcoded in the first stage) of the second stage image.
We should certainly publish seperate signatures for the floppy images on the ftp site (public key signed ones).
In future releases, (detached) signatures {c,s}hould be put in the images directory. a signed MD5sumss file could be put in the base directory for the various stages.
as for the chicken/egg problem of where to get the signature from: If the public key is available from the website then that could be used to check the (detached) signature of the boot floppies and of the key file(s) on the install CD. Once checked those files would be used in the boot process. Most people already have the signatures from older releases, so you don't have to trust the website absolutely.
Jeremy, This has been open for a long time. Whats your take on this? If the current method of checking md5 is documented in the download page, installation guide and release notes that should provide enough information for the users to reasonably protect themselves from malicious mirrors. Would any additional information on the signatures of the ISO images in a prominent place help?
Adding relnotes to the CC list so that that release notes writers document whatever is worthy enough to include in it related to this report
Checking the MD5 sums is insufficient unless the source of the MD5 sums is itself signed. Or am I missing something?
All of the RPMS are signed already with the Fedora GPG keys. http://fedora.redhat.com/about/security/ All of the download images have a sha1sum checksum http://fedora.redhat.com/download/
Rahul -- the problem is that the installer doesn't check GPG keys. And if you are doing a net install as described here, you won't have an image to check the checksum of.
Matthew Miller, What kind of net installation are you describing now. There is no supported methods of using a floppy to do this anymore. Do you mean that the boot.iso doesnt have a published sha1sum checksum? Assuming it does, what exactly is the security issue here?
Look at the original description above. The boot.iso checksum covers the first problem, but nothing addresses the second.
(Unless there's been a change with the yum-based installer I haven't looked at yet.)
FTP and NFS installs (using the boot.iso image) implicitly trust that the NFS/FTP repository that RPMS are being taken from have not been compromised. There is, (within anaconda) no way to test this as part of the installation process. anaconda should have the option to check the GPG signatures of packages before they are installed, and this option should default to on for network (NFS/FTP) installations. I'm willing to argue about HD installs, since they be created on Windows, where the necessary tools are unavailable. It's 10:00. Do you know where your RPMS came from?
Comment #8 is just as valid today as it's always been. And it unfortunately will get more complicated in the future, not less. But that doesn't mean that I don't still think it needs addressing somehow, which is why it continues to stay open.
Yeah. But even if the public key is on the boot.iso, that's much easier to verify. (Maybe I give it to you on CD. Or at least you can check the checksum.)
Comment #8 is not very valid - and there is no chicken-egg problem. The process is supposed to work as follows: 1) User downloads the Fedora public key and validates it via the GPG web-of-trust or some other means. 2) User downloads the boot.iso and boot.iso.asc and checks the signature. 3) User boots off the boot.iso, which includes the installer that contains the correct GPG public key and will perform the signature checking on all that it downloads.
The problem is what do you do if an organization is adding packages to the tree without changing the other stuff (which I would tend to encourage _against_ as changing the images is a bit likely to hit problems). If they sign their packages, they're not going to be signed with the Red Hat/Fedora key and so just having keys in the boot.iso isn't good enough. This is going to become an even bigger concern as multiple repository support lands.
Conversely, I'd *really* like my installer to not be able to install any packages I haven't signed -- not even you folks until I've tested 'em. :) But yeah, with multiple repos, more of a problem. But there's also already the problem of getting all of the rest of the per-repo config info in place, ideally without filling out too many tedious details. How do you feel about yum's current auto-key-fetch mechanism? So each repo would specify where to get its key, and then anaconda would get it and present the fingerprint for manual verificion... Not that anyone would actually check, but in theory they could.
A couple of things to do with multiple reositories: First of all, Fedora *already* has multiple repositories (core and extra). What might work would be a pool of keys (e.g. in a specific directory on the install image) which are available to check the RPMS. That way, users could verify the various keys before an install, and then choose which ones they trusted during the install process (or if they wanted to use keys at all).
(In reply to comment #27) > A couple of things to do with multiple reositories: > > First of all, Fedora *already* has multiple repositories (core and extra). What > might work would be a pool of keys (e.g. in a specific directory on the install > image) which are available to check the RPMS. That way, users could verify the > various keys before an install, and then choose which ones they trusted during > the install process (or if they wanted to use keys at all). Fedora has multiple repositories but the installer itself doesnt support it. When the installer starts supporting in the subsequent releases as planned, this becomes a bigger concern. Perhaps using the yum backend and auto key fetching mechanism as commented upon above would resolve this.
So: is FC6 a good time to kill the last open 3-digit bug? :)
It just hit me that multiple repositories aren't that big of a problem -- that's what the web of trust is for. Red Hat can have a repository signing key that signs the keys used in 'trusted' repositories. This would not give automatic trust to those repositories, but people could, at least, be able to trust those second/third level keys with some level of knowledge that they are, at least, not using completely anonymous keys.
My thoughts: 1. Chicken-and-egg: What can you trust? At some point, people just have to apply a certain degree of faith. As long as their is a complete chain of cryptographic signatures, we simply have to provide a single trusted source. That source would most likely be the websites, where we already have SHA1 checksums provided. Users must simply be able to have faith in our websites. 2. Chain formation: * We provide checksums for the images on the websites. * When creating repository configurations for yum, we provide GPG key locations. * We provide key fingerprints for our repositories on the websites. * We place configurations and keys for regular repositories on the install media. * Anaconda asks for additional repository information at install time. * During the installation, missing GPG keys are downloaded *before* installation. * The downloaded key fingerprints are presented to the user by Anaconda. * The user can compare fingerprints to those from the websites. * Third-party repositories can provide the same information. * The user has an opportunity to approve or refuse each key. * Anaconda asks the user whether or not to trust unsigned or unverified packages. * Anaconda uses yum to download the packages and verify signatures. Am I missing anything?
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
*** Bug 388741 has been marked as a duplicate of this bug. ***
For comment #25, it just hit me that it could/should be possible for an installer to: 1) turn off GPG checking, 2) turn GPG violations into warnings only, and/or 3) supply other keys to accept as valid.
Until anaconda learns how to verify signed packages I suggest adding '--nosignature' option to the rpm installation transaction to suppress misleading messages like 'warning: setup-2.6.12-1.fc9: Header V3 DSA signature: NOKEY, key ID 30c9ecf8'.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 471775 has been marked as a duplicate of this bug. ***
*** Bug 509338 has been marked as a duplicate of this bug. ***
Related: bug 588362.
I don't know if I have to state the obvious: Without verifying signatures the network-install feature in the installer is unusable. I suggest that - until this issue is fixed - the installer displays a big warning (about the security implications) when the user choses a network install. I installed FC14 over the net from a mirror because I assumed that in 2011 the signature verification of binary packages is a de-facto-standard. I was wrong. Now I have wasted some time, I have to wipe the install, download the full iso and install FC14 from it again.
Let me add my use case: I'd want to install *latest* Fedora bits from media + primary repo + updates repo. The installation media is obtained from a trusted source and contains GPG keys which are valid for updates too. I think this scenario can be supported without any problems. I understand that 3rd party repos are diffrerent story, but installing Fedora + 3rd party repos could still fall back to what Georg described in comment#40 (a big warning about security implications).
(In reply to comment #41) > I understand that 3rd party repos are diffrerent story, but installing Fedora + > 3rd party repos could still fall back to what Georg described in comment#40 (a > big warning about security implications). 3rd part repos still could be resolved without a big fat warning, provided that at least GPG key (and perhaps some checksum file of something) is provided over https:// (certificate verified against /etc/pki/tls/certs/ca-bundle.crt, which after bug 599040 should be provided, right?).
(In reply to comment #42) > 3rd part repos still could be resolved without a big fat warning, provided that > at least GPG key (and perhaps some checksum file of something) is provided over > https:// (certificate verified against /etc/pki/tls/certs/ca-bundle.crt, which > after bug 599040 should be provided, right?). No, except for cases when the server certificate is already signed by a well-known authority. Bug 599040 only allows you to force using untrusted https (we can't verify it is a valid host, but we still want an encrypted connection).
I remember now that one of our concerns was stage2 integrity checking. Since we moved to one big image this is also no longer a problem.
Regarding comment #25 and comment #34: yes, please. I would like to sign my packages, add them to the media, and do network installs. My current reason for doing network installs is so that I can do automatic testing.
This is why I don't use KDE.
(In reply to John Dulaney from comment #49) > This is why I don't use KDE. Someone may wish to correct me, but - to clarify for anyone reading down this far - (as far as I understand it) this bug has nothing to do with any desktop environment. It hits all network installs/upgrades, whether they are on a desktop machine or a headless server.
Just had a 'crazy' 'early morning' though about this. I'm not an anaconda expert by any means, but figured I'd throw this out there and see if it floats, is already floating or sinking. It's not uncommon for remote machines to keep LUKS keys on a USB stick plugged in to a machine. I'm wondering if it's not possible to also read the needed bits for the GPG/Certs for the install phase off the key as well. As I say, don't know if this is already doable, let alone how. I'm imagining some kernel flag/s at install time. It wouldn't fix all cases, such as those machines which can't take a USB stick (either by policy or physical design), but it'd be something at least. Anyway, as I say, I realise it's a completely clueless question/suggestion that I'm more than happy to be shot down in flames over :)
*** Bug 1090682 has been marked as a duplicate of this bug. ***
Echoing (I think) Aleksey Nogin and Daniel Mach: I don't understand the security concern with baking the public key into the network install image. If the network install image is untrustworthy, then the installed system is untrustworthy forever, since a malicious install image can simply install a rootkit (or, for example, a patched version of yum that always accepts packages signed with a malicious key). Therefore, to have any security at all, it is necessary to perform out-of-band verification of the install image (e.g., use an existing trusted machine to get the signing key over HTTPS, download the signed checksums file, verify its signature, then download the image and verify that its hash matches the checksums file). But this verification is also sufficient to ensure that any public key baked into the network install image is authentic. So there is no real "bootstrapping" or "fidelitas ex nihilo" issue. It sounds like a similar conclusion has been reached on #748320, but the discussion on #1090682 contradicts this. Am I missing something?
I verified that this bug has been resolved in the Fedora 20 netinst images. The mirror list is downloaded over HTTPS from mirrors.fedoraproject.org, and it contains a hash of the repomd.xml file, and the hash chain down to the individual RPM package files is verified. Specifically, I checked the following: If mirrors.fedoraproject.org serves a trust X.509 certificate for the wrong host name, the download fails. If mirrors.fedoraproject.org uses a self-signed certificate for the correct host name, the download fails. If mirrors.fedoraproject.org is not tampered with, but the repomd.xml file is changed, the download is discarded and another mirror is attempted, until the download has the expected hash. The same thing happens with the primary.sqlite.bz2 file (with an unaltered repomd.xml file): multiple mirrors are tried until the download succeeds. And if I edit the RPM files as they are downloaded (with a correct primary file), this also triggers a switch to a different mirror.
(In reply to Shivaram Lingamneni from comment #53) > Therefore, to have any security at > all, it is necessary to perform out-of-band verification of the install > image (e.g., use an existing trusted machine to get the signing key over > HTTPS, download the signed checksums file, verify its signature, then > download the image and verify that its hash matches the checksums file). One of the reasons this was still left open is that with current technology, there's no reason this should be out of band - on current generation hardware, our kernel is verified by the system firmware. As a result, it's possible *not* to rely on external verification.
(In reply to Peter Jones from comment #55) > One of the reasons this was still left open is that with current technology, > there's no reason this should be out of band - on current generation > hardware, our kernel is verified by the system firmware. As a result, it's > possible *not* to rely on external verification. We (Fedora, Red Hat, and others) have shipped signed installers which run unsigned code with out any verification, so firmware verification of installers does not provide any security, unfortunately. A previous discussion is here: https://lists.fedoraproject.org/pipermail/devel/2013-January/176051.html
On Debian, kernels are unsigned but I cannot see any security hole on the network installation of Debian, when the installation media as well as the GPG key shipped inside are pre-verified. I think the problem is that the package list is signed on Debian (Release and Release.gpg), but only the package are signed, not the package list (repomd.xml). BTW anaconda users cannot specify signatures for custom repositories. While it may not be a problem inside big companies where repositories are trusted, amateurs using mirrors provided by their college or other third-party providers could be under MITM attack, especially when the mirror is not added to the metalink list specified by mirrors.fedoraproject.org.
(In reply to Matt Wilson from comment #1) > We can not ship PGP. Well I wonder whether PGP can be shipped in 2017 when other Linux distributions do ship. Thank you very much.
This is still a problem, *22 years later*
(In reply to Neal Gompa from comment #59) > This is still a problem, *22 years later* Please provide more context. At one point in time, it was definitely fixed because we had a cryptographically validated chain (through the mirror manager and repomd digests).
(In reply to Florian Weimer from comment #60) > (In reply to Neal Gompa from comment #59) > > This is still a problem, *22 years later* > > Please provide more context. At one point in time, it was definitely fixed > because we had a cryptographically validated chain (through the mirror > manager and repomd digests). There is no ability to do GPG verification of repomd or RPM packages. This is *mandatory* for having that validation chain for CentOS, Qubes OS, and many other Fedora derivatives.
There is a set of PRs implementing required features: https://github.com/rhinstaller/anaconda/pull/375 https://github.com/livecd-tools/livecd-tools/pull/14 https://github.com/pykickstart/pykickstart/pull/32 https://pagure.io/pungi/pull-request/63 Some went stale already, but if there is someone willing to actually review and merge them, I can provide updated version.