My GnuPG client automatically refreshed the keys in its keyring from a keyserver, and it imported a poisoned key. How can I fix my keyring without merely deleting the poisoned public key?
Last month a number of high-profile pgp certificiates were attacked via a Certificate Flooding attack (CVE-2019-13050) by spamming their public key with tens of thousands (or hundreds of thousands) of signatures and uploading their poisoned public keys to keyservers.
If, for example, you had the "Tor Browser Developers (signing key)" in your keyring and you attempted a --refresh-keys
from a keyserver after 2019-06-30 (when their key was flooded with 121,000 bogus signatures), then your gpg (and consequently your email if for example you're using thunderbird with enigmail) will hang and become unusable.
Most of the coverage of this issue say that the solution is to merely delete the key — but how can I clean the public key locally without having to download a fresh copy (which introduces unnecessary vectors for tampering)?
Best Answer
I spent some time looking into how to fix this, and I published an article about it on my website. Below is a summary of the solution to this question.
1. Identifying the poisoned key
First, we can list the size the public keys in our keyring (in bytes) using the following command (as reported on the GnuPG issue tracker):
If the above command takes longer than a few seconds to run, then you have a problem. Give it 20 minutes or so, and you'll see problematic keys at the bottom. Anything with 8 digits (>10 MB) is a red flag.
2. Exporting the poisoned key
Now that we've identified the poisoned key, let's export it for safe keeping before we delete it.
After a few minutes, the command will finish, and you should have a file named
pubkey.asc
with the contents of the poisoned public key in it. Note that this ASCII armored file containing exactly one public key is 22M!3. Deleting the poisoned key
Now that we have a safe backup of the poisoned key on disk, let's delete it from our keyring.
4. Re-importing the cleaned key
To re-import a clean copy of the public key, we'll use the
gpg
argument--import-filters
to drop all signatures (drop-sig
) made on the date when the certificate was flooded with signatures.Given a public key file (like the backup we just exported above), we can list a count of the number of signatures that certificate received for each day with the following command:
The above output shows that
We can import the key while omitting these spammed signatures on these two days as follows (be sure to replace the dates with the corresponding days printed from the above command on your machine):
And now things should be much more sane:
5. Updating your GnuPG config
As Robert J. Hansen (whoose pgp key was spammed with 149,100 signatures on 2019-06-19) pointed out in their excellent comprehensive gist about this issue, you can prevent your gpg client from breaking itself by:
That
keys.openpgp.org
keyserver is a new experimental server (interestingly, it went live just weeks before these poisoned certificates were uploaded) that is more resistant to these attacks. Note that the certificates it serves entirely lack third party signatures, and it also strips the UID packets from the key unless a user explicitly opts-in.6. Updating your MUA config
You may also need to update your MUA. For example, enigmail in thunderbird may also be configured to update the keys in your keyring.
To prevent enigmail from refreshing your keys from a keyserver, go to your thunderbird preferences -> Advanced -> Config Editor... -> I accept the risk!
And set
extensions.enigmail.keyRefreshOn
tofalse
Addendum
Note that the keybox keyring format will refuse to import posioned keys as it has a max key size of 5 MiB, and that users with old installs should consider migrating their keyring to keybox format.
This can be done easily in debian-based systems using the migrate-pubring-from-classic-gpg command