Yum/RPM And Trust On First Use

Home » CentOS » Yum/RPM And Trust On First Use
CentOS 15 Comments

I’m not on the yum / RPM list and I don’t know that I want to join just to discuss this but with respect GPG keys – it is a classic example of trust on first use.

The first time yum installs a package, it asks to import the GPG key used to sign the packages. Most people accept without validating the key.

This is potentially exploitable because most repositories are http

What if there was a DNS TXT record that corresponds with the repository, with the fingerprint of the key?

The DNS record could be DNSSEC secured (I believe Fedora already uses DNSSEC – some of their servers anyway) and yum could refuse to ask if the fingerprint of the key it is importing does not match the DNSSEC
secured fingerprint.

Something like TXT record for

_rpmkey.security.CentOS.org.

could be requested for the fingerprint for security@CentOS.org

Advantage over gpg keyrings is that it can be implemented by anyone without needing to manage your keys with specific gpg keyrings, which has always been messy.

When yum is first asked to import a key, it refuses if it can not DNSSEC
validate the fingerprint.

After it DNSSEC validates the fingerprint, it can then does what it currently does, where the user can verify they trust the key.

To get a fingerprint in the CentOS.org zone and signed by DNSSEC would not be easy for a malicious packager to do.

Furthermore when a signing key has been compromised (happened with Fedora once) changing the DNS record would prevent the key from being imported in the future, and could even prevent packages signed by that key from being installed in the future even if the key is already imported.

For offline yum usage, a switch could be used to tell yum not to do the DNS lookup and DNSSEC validation.

Thoughts?

15 thoughts on - Yum/RPM And Trust On First Use

  • This is a huge issue, its something we’ve debated many times and I dont think there is a clear answer, yet. At this point we have yum use the gpg keys setup at install time, from the install media – it should not be going over the wire to grab keys. And we sign the install media, and its sha sum’s – so uses can verify things.

    the underlaying thinking being that if the install media is compromised, anything it does and any content it grabs over the wire should be considered potentially compromised – so enforce the idea of media test, media validation, and deliver the first ring of trust via the media.

    Having said that, your point about using DNS as a second way to verify the keys is a good one, I believe its come up in the past as well. And we have a todo item to get dnssec up for CentOS.org in the near future. what I would recommend, is to open an issue report at bugs.CentOS.org/
    to track this as a task.

    As a related subject, we do push the main key fingerprints via https at http://www.CentOS.org/keys

    regards

  • While that is true, it is important to note that yum will only import keys that are already installed on disk, in /etc/pki/rpm-gpg. Which means that only keys that were *previously* installed from a trusted source can be added to the trust database. Initially, that set comes from your install media. Assuming that you verified the sum of the media you used for installation, this is a reasonably secure mechanism.

    http repositories don’t impact the security of this mechanism in any way. If you’re worried about the package verification process, the big risk that exists in the current implementation (assuming that you trust your install media) is that users are allowed to install repositories that are configured with both gpgcheck=0 AND an http:// URL. That combination could lead to a compromise through a MITM attack, but only if a third-party repository is added, and that repo doesn’t provide any security at all.

    …

    And what should it do at sites where there’s no DNSSEC validation available? Are they unable to install packages?

    Should it fall back to its current behavior? I think that’s an important question, because if you’re trying to improve security in the face of a MITM attack, you have to be able to demonstrate that security is actually better *during an attack*. If a MITM can simply cause the client to fall back to its current behavior in order to launch a hypothetical attack, your solution isn’t suitable.

    If you’re going to verify the key against a DNS record for every package you install, forever, why have a GPG keyring at all?

  • With third party repositories the key and configuration file is often distributed separately. That’s the potential attack vector for trojan keys.

    Well I’m not a big fan of GPG keyrings to be honest, it is a difficult system for users and contains abandoned keys and compromised keys that aren’t revoked because the owner can’t revoke them if they lost their private key.

    DNS verification solves that issue.

  • How reliably safe is that ?
    Crack the DNS access and inflict viruses, trojans etc. with authorised impunity ?

    Happy Christmas.

  • No, if you manage to crack the DNS you can not do anything but a DOS
    attack unless you also managed the get the DNSSEC signing key, which does not need (and should not be) to be on the DNS server.

    Manage to get the signing key, and the only consequence is the attacker can make fraudulent DNS entries that would validate – same as with GPG
    or any other private / public key cryptographic signatures.

  • Examples?

    All of the notable repositories that I’m aware of publish an x-release.rpm that installs their key and yum repo file. But if your concern is that users might manually install a repo file and public key, then I don’t see how modifying yum would change that. The attacker would probably include a key that contains an address they control and validates properly against it.

    In other words, I think the solution to the problem is simply to make sure that the repositories publish their “release” rpm over https and that documentation reflects the secure URL. I notice now that EPEL
    links directly to the https URL for their release rpm, but their FAQ
    still provides a command-line example for installation using an http URL.

    The FAQ should be updated. That method is a potential security problem because it doesn’t use https and doesn’t check the package signature.
    But the solution is simply to replace http with https in the FAQ. yum isn’t used to install the release package, and I think the solution is to make sure that malicious release packages don’t get installed, not to try to behave well on a system where an attacker already installed malicious data.

  • Yes, but I’ve run into instance where curl does not work for https – for example I believe if ECDSA TLS certificate is being used on the server, curl doesn’t work. Not sure about wget.

  • did you mean Yum ? rpm is just a file format for packages, and a package installer program, its yum that does the network operations to fetch the packages, and as far as I understand it uses libcurl, so it should be able to support https

  • RPM has ability to install a package over the network.

    rpm -i ftp://example.org/foo-2.2.noarch.rpm

    could be used to install that package, which may contain the key and yum configuration for a third party package.

    The point I’m trying to make though is that yum could benefit from the ability to verify the fingerprint in a key it is importing matches a DNS
    query for the user and domain the key claims to be for.

    Regardless of how the package was retrieved, this could prevent dishonest trojan keys from being imported, especially if DNSSEC
    validated the DNS query.

  • Thanks for the new knowledge.

    How widespread is the problem of unknowingly importing compromised software ?

  • Why do you think the solution is to make yum behave well when there’s malicious data in /etc, rather than updating rpm/curl to properly support https so that it doesn’t get there?

  • I think we understand your point. The solution that you’re proposing guards the system against compromise from data that’s already in /etc. In my mind, that’s too late. An attacker that can put data in /etc can overcome any protections you put in place. I agree with you that packages should never be installed by rpm over http/ftp, because there’s no signature verification in that case. But yum isn’t involved in that, so I can’t see a rational case for modifying yum to protect the system after you install an untrusted rpm. It sounds like you’re trying to close the barn door after the horses have already left.

    In any case, development of yum has ended. It’s been replaced by dnf. And this is the wrong place to discuss improvements to either. CentOS
    is a rebuild of Red Hat and nothing more. Improvements need to happen further upstream.

  • It’s a validation step.

    Even with https – fraudulently signed certificates are still a problem, as well as the issue of there not being any RFC stating what certificate authorities must be trusted.

    So if a server serves an RPM over https – it has to be with a certificate signed by an authority trusted by client. There’s no way to guarantee that.

    DNSSEC validation doesn’t have that issue.