[BUG REPORT] openSUSE zypper failure with all gpg versions > 2.2.6

[Daniel Kahn Gillmor]

On Thu 2020-03-26 09:57:16 -0700, James Bottomley wrote:
>> a backtrace of the code around the call to gpgme_op_verify would be
>> helpful.
>
> It's in the missing email ... if you can't free it from moderation, I
> can break it up.

thanks Werner for releasing the message from moderation.

The relevant bits seem to be (i've tried to un-linewrap them, pls let me
know if i got it wrong):

  2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(readSignatureKeyId):611 Determining key id of signature /var/cache/zypp/raw/jejb-tumbleweedSd4soS/repodata/repomd.xml.asc
  2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp::gpg++] KeyManager.cc(createForOpenPGP):239 createForOpenPGP(/var/tmp/zypp.SwKyrE/PublicKey)
  2020-03-19 08:08:14 <3> jarvis.int.hansenpartnership.com(13858) [zypp::gpg] KeyManager.cc(readSignaturesFprsOptVerify):174 <GnuPG> General error
  2020-03-19 08:08:14 <1> jarvis.int.hansenpartnership.com(13858) [zypp::KeyRing] KeyRing.cc(verifyFileSignatureWorkflow):515 File [/var/tmp/AP_0xOFkuw6/repodata/repomd.xml] ( repomd.xml ) signed with unknown key []

So it is indeed failing during an attempt not to verify the signature,
but an attempt to verify the key IDs *in* the signature.

I can try to debug this in gpgme further, but i want to point out a
problem with the pattern that libzypp (or maybe zypper itself) is using
here.

the workflow seems to be:

 - verify that <sig> contains a valid signature over <data>
 
 - get a list of keys that are present in <sig>, and ensure that some
   key is in a "known good" list. 

(maybe not in that order -- it doesn't matter)

The risk is that <sig> could contain multiple signatures.  Some of them
could be from the known-good list, and others not.

I don't have the time right now to try to attack zypper or libzypp right
now, to make sure that it's not vulnerable, but if i were responsible
for that tool, i'd want to audit it much more closely, and make a few
different test cases of attempted attacks, to make sure that they fail.

Feel free to contact me privately if you want to talk about this kind of
auditing/testing in a less public channel.

The better way to do the check you're trying to do is to get the list of
signing keys from the verification result itself. Do you see how this is
a security improvement?

As a side benefit, if you do this the way i describe above, you'll avoid
this extra attempt to get a list of key IDs from <sig> itself, which is
where the code is failing today.

These tools are still pretty clumsy and *way* too difficult to use
correctly, even for capable programmers like yourself.  It's not your
fault for "holding it wrong" -- i'm just trying to help you think
through ways that you could do it better.

If you're interested thinking through simpler programmatic ways to do
what i think libzypper is trying to do (verify signature(s) that are
expected to come from one or more OpenPGP certificates in a curated
keyring), i'd welcome your feedback on
https://tools.ietf.org/html/draft-dkg-openpgp-stateless-cli.

Regards,

    --dkg
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200327/27470353/attachment.sig>