bug in gnupg handling of revoker signatures

Daniel Kahn Gillmor dkg at fifthhorseman.net
Fri May 7 08:34:08 CEST 2010


Hi GnuPG folks--

I think gnupg does not handle self-signatures that indicate revocation
keys [0] properly.

Consider key C108E83A, which i've made to demonstrate this bug.

At the bottom of this message are two copies of the same key.  The first
copy has an indication that my key (D21739E9) is allowed to revoke
certifications by it. The second copy has a deliberately broken (that
is, not cryptographically-valid) revocation certification, indicating
that a key with fingerprint 0x000...001 is allowed to revoke it.  I
created this bogus version by just swapping out the fingerprint bytes in
the signature made over the primary key.

If the local keyring has the bogus version installed, then importing the
good key will fail to update gpg's revoker information.

That is, save the two versions of the key below as bogus.key and
good.key compare the output of:

 gpg --delete-key C108E83A
 gpg --import bogus.key
 gpg --import good.key
 gpg --list-keys --with-colons C108E83A

with:

 gpg --delete-key C108E83A
 gpg --import good.key
 gpg --import bogus.key
 gpg --list-keys --with-colons C108E83A


The final versions should be identical, but (at least for me, with gpg
versions 1.4.10 and 2.0.14 on debian testing) the former shows no rvk:
line, while the latter shows an rvk: line.

Compare also the output of "gpg --export C108E83A | gpg --list-packets"
with these two states.  It appears to be "first revocation certification
received wins", even if one of them is cryptographically unsound.

This is a potential security problem, because it suggests that a
malicious user could block the distribution of revocation indicators.  A
user who relies on published revocation certifications may not have them
treated properly if a malefactor produces a modified or simply corrupt
revocation certification that somehow overrides the first.

It appears that fetching the good key material from the keyservers does
not fix the problem either.

If i can provide more information, please let me know.

Thanks for gpg,

	--dkg

Here is the good version of the key:


-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.10 (GNU/Linux)

mI0ES+OoSQEEAJUZ/+fC6DXN2X7Wxl4Huud/+i2qP1hcq+Qnbr7hVCKEnn0edYl+
6xfsKmAMBjl+qTZxPSDSx4r3ciMiIbnvXFtlBAQmji86kqoR6fm9s8BN7LTq7+2/
c2FHVF67D7zES7WgHc4i7CfiZnwXgkLvi5b1jBt+MTAOrFhdobxoy6/XABEBAAGI
twQfAQIAIQUCS+OsRRcMgAEO5b6XkoLYC591QPHM0u2U0hc56QIHAAAKCRA0t9EL
wQjoOrRXBACBqhigTcj8pJY14AkjV+ZzUbm55kJRDPdU7NQ1PSvczm7HZaL3b8Lr
Psa5c5+caVLjsGWkQycQl7lUIGU84KoUfwACQKVVLkqJz8LkL54lLcwkG70+1NH5
xoSNcHHVbYtqDLNeCOq5jEIoXuz44wiWVEfF+/B115PvgwZ63pjH1rRGVGVzdCBL
ZXkgRGVtb25zdHJhdGluZyBSZXZva2VyIFRyb3VibGUgKERPIE5PVCBVU0UpIDx0
ZXN0QGV4YW1wbGUubmV0Poi+BBMBAgAoBQJL46hJAhsDBQkACTqABgsJCAcDAgYV
CAIJCgsEFgIDAQIeAQIXgAAKCRA0t9ELwQjoOgLpA/9/si2QYmietY9a6VlAmMri
mhZeqo6zyn8zrO9RGU7+8jmeb5nVnXw1YmZcw2fiJgI9+tTMkTfomyR6k0EDvcEu
2Mg3USkVnJfrrkPjSL9EajW6VpOUNxlox3ZT1oyEo3OOnVF1gC1reWYfy7Ns9zIB
1leLXbMr86zYdCoXp0Xu4g==
=xsEd
-----END PGP PUBLIC KEY BLOCK-----


And here is the modified/bogus version of the key:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.10 (GNU/Linux)

mI0ES+OoSQEEAJUZ/+fC6DXN2X7Wxl4Huud/+i2qP1hcq+Qnbr7hVCKEnn0edYl+
6xfsKmAMBjl+qTZxPSDSx4r3ciMiIbnvXFtlBAQmji86kqoR6fm9s8BN7LTq7+2/
c2FHVF67D7zES7WgHc4i7CfiZnwXgkLvi5b1jBt+MTAOrFhdobxoy6/XABEBAAGI
twQfAQIAIQUCS+OsRRcMgAEAAAAAAAAAAAAAAAAAAAAAAAAAAQIHAAAKCRA0t9EL
wQjoOrRXBACBqhigTcj8pJY14AkjV+ZzUbm55kJRDPdU7NQ1PSvczm7HZaL3b8Lr
Psa5c5+caVLjsGWkQycQl7lUIGU84KoUfwACQKVVLkqJz8LkL54lLcwkG70+1NH5
xoSNcHHVbYtqDLNeCOq5jEIoXuz44wiWVEfF+/B115PvgwZ63pjH1rRGVGVzdCBL
ZXkgRGVtb25zdHJhdGluZyBSZXZva2VyIFRyb3VibGUgKERPIE5PVCBVU0UpIDx0
ZXN0QGV4YW1wbGUubmV0Poi+BBMBAgAoBQJL46hJAhsDBQkACTqABgsJCAcDAgYV
CAIJCgsEFgIDAQIeAQIXgAAKCRA0t9ELwQjoOgLpA/9/si2QYmietY9a6VlAmMri
mhZeqo6zyn8zrO9RGU7+8jmeb5nVnXw1YmZcw2fiJgI9+tTMkTfomyR6k0EDvcEu
2Mg3USkVnJfrrkPjSL9EajW6VpOUNxlox3ZT1oyEo3OOnVF1gC1reWYfy7Ns9zIB
1leLXbMr86zYdCoXp0Xu4g==
=YV5g
-----END PGP PUBLIC KEY BLOCK-----

[0] http://tools.ietf.org/html/rfc4880#section-5.2.3.15

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 892 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20100507/edd6c0f5/attachment-0001.pgp>


More information about the Gnupg-devel mailing list