Page MenuHome GnuPG
Create Task
Maniphest T4136

--recv-keys With Short IDs Is Insecure, Is Actively Being Attacked, And Should Be Removed Entirely
Closed, WontfixPublic
Actions

Description

Somebody has created and deployed a tool which duplicates all of the important short IDs on the SKS keyservers. As a result, adding a key for many important projects - including in the way that their documentation instructions - now also adds "Totally Legit Signing Key <mallory@example.org>".

You can read more about this here:
https://seclists.org/oss-sec/2018/q3/174

The tool to perform the collisions is here:
https://github.com/jwilk/stopgp32

We got burned by this yesterday. Fortunately, the author is just trying to make a point and isn't doing anything malicious, but it would have been trivial for him or anybody else to cause serious damage.

Since it's trivial to spoof short IDs, I strongly recommend that this feature be disabled entirely and that only _full_ identifiers be used - even 64-bit identifiers are brute forceable for anybody with access to a well funded AWS account.

Event Timeline

Miserlou created this task.Sep 7 2018, 5:23 PM
Miserlou added a comment.EditedSep 7 2018, 5:28 PM

Here's an example of a bad key: http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x4359ED62E084DAB9
which mimics the good key for R-CRAN: http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x51716619E084DAB9

Installing this with their official documentation would cause the malicious key to be installed (apt-key adv --keyserver ha.pool.sks-keyservers.net --recv-keys E084DAB9).

Searching for "Totally Legit Signing Key <mallory@example.org>" on Google reveals that there are people all over StackOverflow and GitHub who have been hit by this and not even realized it for other projects such as MongoDB and RVM.

Miserlou added a comment.Sep 9 2018, 7:18 PM

..anybody?

• werner closed this task as Wontfix.Sep 10 2018, 7:58 AM
• werner claimed this task.
• werner added a subscriber: • werner.

This has always been the case and the worst thing which can happen is that (64 bit keyid clash) you might not be abale to import the "real" key. Keyserver's never promised to deliver the correct (in whatever sense) key, but are merely an anonymous and distributed stoarage systenms. This is why gpg does not trust a key by default but requires you to validate the key by other means (WoT, second channel, Web Key Directory).

Note also that gpg does not show the keyid anymore by default but instead shows the fingerprint and in addition in a way that it is easy to c+p.

This is not a topic for the bug tracker but should be discussed at gnupg-devel (for the nth time ;-).

• werner added a comment.Sep 10 2018, 8:04 AM

You may indeed post to gnupg-devel if that helps to raise the attention of the Travis folks. If they need support we would be glad to help.

jwilk added a subscriber: jwilk.Sep 16 2018, 11:39 AM