CVE-2019-13050: Certificate spamming attack against SKS key servers and GnuPG

Updated -

Background

OpenPGP is a non-proprietary protocol for signing and encrypting email communication using public key cryptography. Based on the original PGP (Pretty Good Privacy) software, the OpenPGP protocol defines standard formats for encrypted messages, signatures, and certificates for exchanging public keys. There are several open source implementations of OpenPGP, including GnuPG which is shipped with Red Hat products.

Key servers are used to facilitate the distribution and discovery of public certificates.Users can search the key server by a variety of different criteria to discover public certificates which claim to belong to the desired user. The key server network does not attest to the accuracy of the information, that's left for each user to ascertain according to their own criteria. SKS is one such implementation of key server which is widely used for distribution of public certificates.

Once a user has verified a certificate really and truly belongs to the person in question, they can optionally affix an affidavit to the certificate attesting that they have reason to believe the certificate really belongs to the user in question. This is known as signing the public certificate.

Vulnerability

The SKS key server network is susceptible to attacks as a consequence of its write-only design. As discussed above, certificates can be signed by users. These signatures are stored on the key server and are never deleted even if the certificate is revoked.

The OpenPGP specification puts no limitation on how many signatures can be attached to a certificate. The key server network handles certificates with up to about 150,000 signatures.

The vulnerability lies in the inability of the GnuPG client to handle certificates which have a large number of signatures. Certificates maliciously signed by a large number of attackers are called spammed or poisoned certificates and the resultant attack is known as a certificate spamming attack.

When an attempt is made to import or verify such a certificate (via the key server), it results in a denial of service attack against the local per-user GnuPG instance and it is rendered unusable.

In June 2019, attackers deployed a certificate spamming attack against two high-profile contributors in the OpenPGP community. Poisoned certificates are already present on the SKS key server network. The attackers may have poisoned other certificate on the network also.

This attack cannot be mitigated by the SKS key server network in any reasonable time period. It is unlikely to be mitigated by the OpenPGP Working Group in any reasonable time period. Future releases of OpenPGP software will likely have some sort of mitigation, but there is no time frame.

Impact

Users of GnuPG software

Users of GnuPG who import only locally created certificates or those created within their infrastructure and later use them for verification are not affected by this flaw. Unless the keys are refreshed from the public key server, the GnuPG installation is not exposed to his flaw. Users are advised to disable key servers in their GnuPG configuration file. Detailed instructions are available in the “Mitigation” section below.

Disabling refreshing keys for users of Enigmail extension in Thunderbird

“As of Enigmail 2.0, public keys are automatically refreshed at irregular intervals. You can disable this feature via the Thunderbird "Config Editor". Open the Thunderbird Preferences → Advanced Tab → Config Editor. Then search for extensions.enigmail.keyRefreshOn and set the value to false.”

Package signing

GnuPG is often used to verify downloaded packages for Linux distributions. If someone were to poison a vendor's public certificate and upload it to the key server network, the next time a system administrator refreshed their keyring from the key server network the vendor's now-poisoned certificate would be downloaded. At that point upgrades become impossible because the authenticity of downloaded packages cannot be verified. However Red Hat products, however, are not affected by this attack vector.

Red Hat ships public keys (which can be used to verify the integrity of its signed packages) as RPM-GPG-KEY-* files in the /etc/pki/rpm-gpg directory via the redhat-release-* package. Though the keys are also hosted on key servers and the Red Hat website, we do not expect the customers to install these keys or use them for verification from our website.

Further, GPG keys used by RPM for package verification are not stored in the default location (~/.gnupg) but are directly imported in the RPM database present in /usr/lib/rpm. Similarly package management software like yum and dnf, store their imported public keys in the RPM database as well. These keys are available to users as gpg-pubkey* rpm packages.

Container Images

Container image signature verification is not enabled by default in Red Hat Enterprise Linux, however Red Hat container images delivered from registry.redhat.io and registry.access.redhat.com are signed by the same GnuPG key as Red Hat packages. Container image signature verification can be enabled.

Though container image signatures, like package signatures, are verified with GnuPG, signature verification is not impacted by this issue as the ~/.gnupg store location is not used.

Container image verification can also be enabled by the same mechanism for images from quay.io. However, not all Red Hat container images on quay.io are currently signed.

Mitigations

As per upstream: High-risk users should stop using the key server network immediately.

  1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with key server. If there is, remove it.
  2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line keyserver hkps://keys.openpgp.org to the end of it.

keys.openpgp.org is a new experimental key server which is not part of the key server network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence.

For installations which are currently rendered unusable by this attack, the following repair method is advised:

  1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it.
  2. If you do not know which certificate is poisoned, the best option is to get a list of all your certificate IDs, delete your keyrings completely (rm -rf ~/.gnupg/ then reinstall private and public keys, or restore from backup), and rebuild from scratch using known-good copies of the public certificates.

References

Frequently asked questions

Q: I use GnuPG for signing and verifying artifacts in my organization, am I affected?
A: No, Unless you import or refresh keys from the public SKS key servers, you are not impacted.

Q: Will I be vulnerable to attack if I attempt to verify the integrity of Red Hat packages using GnuPG?
A: No, as described in the section above, Red Hat public keys, which can be used for verification are distributed as an RPM package with the distribution. You do not have to use the key servers for verification.

Q: When will a patch be available for this issue?
A: There is no time frame. This is really a flaw in the OpenGPG protocol and GnuPG is only implementing the protocol. Additionally the SKS key server code has not seen significant changes for a long time. Future releases of OpenPGP software will likely have some sort of mitigation, but there is no time frame.

Comments