Bug 998 - (fidelitas-ex-nihilo) Network install/upgrade is unsafe, should check GPG signatures.
Network install/upgrade is unsafe, should check GPG signatures.
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
high Severity medium
: ---
: ---
Assigned To: Peter Jones
: FutureFeature, Reopened
: 388741 471775 509338 1090682 (view as bug list)
Depends On: 748320 253897
Blocks:
  Show dependency treegraph
 
Reported: 1999-01-30 14:40 EST by Aleksey Nogin
Modified: 2016-02-15 13:21 EST (History)
46 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-08-12 07:42:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Aleksey Nogin 1999-01-30 14:40:44 EST
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.
Comment 1 Matt Wilson 1999-03-13 16:29:59 EST
We can not ship PGP.
Comment 2 Aleksey Nogin 1999-03-13 16:33:59 EST
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?
Comment 3 Matt Wilson 1999-03-13 17:04:59 EST
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.
Comment 4 Aleksey Nogin 1999-11-07 18:31:59 EST
Now that you are using GPG for signatures, would such
signature-checking program make sense?
Comment 5 Jay Turner 1999-12-01 15:58:59 EST
We have added this request to the "wish list" for future releases.
Comment 6 Aleksey Nogin 2002-06-19 20:17:58 EDT
Is this really fixed?
Comment 7 Michael Fulbright 2002-09-30 15:59:58 EDT
Jeremy - can you update this bug if it is now fixed?
Comment 8 Jeremy Katz 2002-10-01 18:09:25 EDT
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.
Comment 9 Aleksey Nogin 2002-10-02 14:05:41 EDT
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.
Comment 10 Alan Cox 2002-12-18 09:38:58 EST
We should certainly publish seperate signatures for the floppy images on the ftp
site (public key signed ones).
Comment 11 Stephen Samuel 2002-12-19 12:56:51 EST
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. 
Comment 12 Stephen Samuel 2003-06-14 10:14:50 EDT
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.
Comment 13 Rahul Sundaram 2005-08-23 19:31:35 EDT
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?
Comment 14 Rahul Sundaram 2005-08-23 19:49:53 EDT

Adding relnotes@fedoraproject.org to the CC list so that that release notes
writers document whatever is worthy enough to include in it related to this report
Comment 15 Aleksey Nogin 2005-08-23 20:33:45 EDT
Checking the MD5 sums is insufficient unless the source of the MD5 sums is
itself signed. Or am I missing something?
Comment 16 Rahul Sundaram 2005-08-23 20:39:04 EDT
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/
Comment 17 Matthew Miller 2005-08-23 20:45:41 EDT
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.
Comment 18 Rahul Sundaram 2005-08-23 20:52:07 EDT
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?
Comment 19 Matthew Miller 2005-08-23 21:00:26 EDT
Look at the original description above. The boot.iso checksum covers the first
problem, but nothing addresses the second.
Comment 20 Matthew Miller 2005-08-23 21:05:55 EDT
(Unless there's been a change with the yum-based installer I haven't looked at yet.)
Comment 21 Stephen Samuel 2005-08-23 21:44:12 EDT
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 22 Jeremy Katz 2005-08-23 22:25:54 EDT
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.
Comment 23 Matthew Miller 2005-08-23 22:29:47 EDT
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 24 Aleksey Nogin 2005-08-23 22:55:29 EDT
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.
Comment 25 Jeremy Katz 2005-08-23 23:02:08 EDT
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.  

Comment 26 Matthew Miller 2005-08-23 23:13:26 EDT
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.
Comment 27 Stephen Samuel 2005-08-23 23:56:20 EDT
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).
Comment 28 Rahul Sundaram 2005-08-24 01:24:01 EDT
(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.  
Comment 29 Matthew Miller 2006-04-13 23:45:04 EDT
So: is FC6 a good time to kill the last open 3-digit bug? :)
Comment 30 Stephen Samuel 2006-04-24 04:13:22 EDT
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.
Comment 31 Patrick Barnes 2006-04-24 22:27:57 EDT
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? 
 
Comment 32 Red Hat Bugzilla 2007-02-05 14:10:40 EST
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Comment 33 Jesse Keating 2008-02-15 16:15:48 EST
*** Bug 388741 has been marked as a duplicate of this bug. ***
Comment 34 Stephen Samuel 2008-02-17 03:17:32 EST
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.
Comment 35 petrosyan 2008-03-28 17:28:31 EDT
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'.
Comment 36 Bug Zapper 2008-05-13 21:54:23 EDT
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
Comment 37 Chris Lumens 2008-11-16 00:26:06 EST
*** Bug 471775 has been marked as a duplicate of this bug. ***
Comment 38 Will Woods 2009-07-02 10:42:53 EDT
*** Bug 509338 has been marked as a duplicate of this bug. ***
Comment 39 Ales Kozumplik 2010-05-27 11:42:39 EDT
Related: bug 588362.
Comment 40 Georg Sauthoff 2011-01-30 19:13:09 EST
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.
Comment 41 Daniel Mach 2011-03-29 08:01:44 EDT
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).
Comment 42 Matěj Cepl 2011-03-29 08:07:49 EDT
(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?).
Comment 43 Ales Kozumplik 2011-03-29 08:15:05 EDT
(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).
Comment 44 Martin Sivák 2011-03-29 10:28:24 EDT
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.
Comment 45 Seth D. Alford 2012-07-10 20:23:46 EDT
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.
Comment 49 John Dulaney 2013-12-16 11:38:55 EST
This is why I don't use KDE.
Comment 50 Peter Lawler 2013-12-16 13:08:24 EST
(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.
Comment 51 Peter Lawler 2014-02-10 15:53:52 EST
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 :)
Comment 52 David Cantrell 2014-04-30 08:38:59 EDT
*** Bug 1090682 has been marked as a duplicate of this bug. ***
Comment 53 Shivaram Lingamneni 2014-07-28 00:32:32 EDT
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?
Comment 54 Florian Weimer 2014-08-12 07:42:28 EDT
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.
Comment 55 Peter Jones 2014-08-12 10:06:39 EDT
(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.
Comment 56 Florian Weimer 2014-08-12 10:49:53 EDT
(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

Note You need to log in before you can comment on or make changes to this bug.