Interaction between the sks-keyserver code through 1.2.0 of the SKS keyserver network, and GnuPG through 2.2.16, makes it risky to have a GnuPG keyserver configuration line referring to a host on the SKS keyserver network. Retrieving data from this network may cause a persistent denial of service, because of a Certificate Spamming Attack. External Reference: https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f https://access.redhat.com/articles/4264021
Created gnupg tracking bugs for this issue: Affects: fedora-all [bug 1726147] Created gnupg2 tracking bugs for this issue: Affects: fedora-all [bug 1726148]
This is essentially a certificate spamming attack, against key servers which use the sks-keyserver software. In June 2019 attackers were able to poison some certificates in the SKS keyserver network. Anyone who attempts to import a poisoned certificate into a vulnerable OpenPGP installation will very likely break their installation in hard-to-debug ways. Poisoned certificates are already on the SKS keyserver network. - This attack cannot be mitigated by the SKS keyserver network in any reasonable time frame. - Currently there is no mitigation or patch available for GnuPG The OpenPGP specification puts no limitation on how many signatures can be attached to a certificate. The keyserver network handles certificates with up to about 150,000 signatures. GnuPG, on the other hand does not. Any time GnuPG has to deal with such a spammed certificate, GnuPG grinds to a halt. It doesn't stops and is rendered completely unusable.
As per the security report: The number one use of OpenPGP today is to verify downloaded packages for Linux-based operating systems, usually using a software tool called GnuPG. If someone were to poison a vendor's public certificate and upload it to the keyserver network, the next time a system administrator refreshed their keyring from the keyserver 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. Even downloading the vendor's certificate and re-importing it would be of no use, because GnuPG would choke trying to import the new certificate. It is not hard to imagine how motivated adversaries could employ this against a Linux-based computer network. Red Hat Signing certificates are available at: https://access.redhat.com/security/team/key A copy of the signing keys are stored on Red Hat website in case the key server is not used. For example: https://www.redhat.com/security/data/897da07a.txt
Statement: This is a certificate spamming attack, against key servers which use the sks-keyserver software. Attackers were able to poison some certificates in the SKS keyserver network. When GnuPG users import these certificate their installations will break. Currently there is no patch available for GnuPG. Users are encouraged to apply the mitigation mentioned on this page. Lastly there is no way to currently detect which certificates have been poisoned. Users of GnuPG who import only locally created certificates or those created within their infrastructure and later use them for verification etc are not affected by this flaw.
Mitigation: As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. 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 keyserver which is not part of the keyserver 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, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
GnuPG upstream has introduced a new command line option called "self-sigs-only" to address this issue. This option is intended to help against importing keys with many bogus key-signatures. It has obvious drawbacks and is not a bullet-proof solution because a self-signature can also be faked and would be detected only later. Reference: https://dev.gnupg.org/T4591 The above mentioned patch and several other improvements in handling this flaw will be available with GnuPG-2.2.17.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:4490 https://access.redhat.com/errata/RHSA-2020:4490
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-13050