[PATCH gnupg] g10/import.c: ignore too large signature packets

[Robert Bartel]

On Fri, 2022-04-22 at 20:40:30 +0200, Werner Koch wrote:
> On Fri, 15 Apr 2022 18:47, Robert Bartel said:
> 
> > A better behavior, instead of failing the public key import, would be to
> > just ignore too large signature packets. This can be achieved with the
> 
> Right.  However, this fixes just one case and has the side-effect that
> it can be used to strip for example an revocation signatures.  This
> might be possible by uploading a signature with extra data the unhashed
> area.  Depends on the keyserver.

Interesting. But this attack with a malicious signature packet already
prevents the user from importing the key and seeing potential other
valid revocation/third party signatures.

When anyone can include subpackets in the unhashed area of any
signature, then an attack would even be easier: just add a single
subpacket with unknown type and the critical bit set. Then the
evaluating software should consider the signature to be in error as per
RFC 4880.

Maybe the unhashed area should be completely ignored regardless its
size to make the implementation more robust for public keyservers.

> > I hope it does not introduce new problems in the code, like missing self
> > signatures when they are too large (will the import fail or lead to an
> 
> Exactly.  Broken keys are broken and should better not be used.

I don't consider the key in question broken. It just happens to have a
single non conforming third party signature on it, which should not
prevent the user from importing it including other valid signatures.

> > Please consider applying the patch upstream or making equivalent changes
> > to the code, to get GnuPG more DoS resistant in the future.
> 
> I am not sure whether this makes a lot of sense given that this is just
> one way to trigger a limit in GnuPG.  The limits have actually been
> implemented to limit the effect of broken keys.

As I understand the RFC the maximum size of the hashed and unhashed
areas is 64k bytes as for the 16 bit length fields. It doesn't seem to
be much of a difference to support the maximum instead of only 10k
today. But then again this could change when you have a lot of those
large signatures added maliciously. This seems to be a general problem
of the append only public keyserver architecture.

Anyway, don't get me wrong, GnuPG already does a great job. But as
always there might be room for improvement. I just don't like the idea
of invalidating an arbitrary key on a keyserver for import by a single
third party signature being so simple.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 313 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220423/ed926c4a/attachment-0001.sig>