Lucene search

K
redhatcveRedhat.comRH:CVE-2019-13050
HistoryApr 02, 2020 - 8:05 p.m.

CVE-2019-13050

2020-04-0220:05:08
redhat.com
access.redhat.com
16

0.01 Low

EPSS

Percentile

83.8%

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.

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.