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

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

Apr 15, 2022, 9:47 AM

Post #1 of 4 (550 views)

Hello list,

I recently noticed a denial of service against the German eID
certification public key from Governikus (https://pgp.governikus.de) on
the keyserver hkps://keyserver.ubuntu.com: Trying to import it from the
keyserver with GnuPG 2.3.4 fails due to a too large signature packet,
which can be reproduced with:

gpg -vv --recv-keys 0x5E5CCCB4A4BF43D7

At the end of the output of this command you can see a signature packet
with a misused policy url field carrying a so called improvement
suggestion in German. This packet is followed by another one which
includes hashed data exceeding the arbitrary size limit of 10000 bytes
from g10/parse-packet.c line 2140, leading to the import error of:

gpg: signature packet: hashed data too long
gpg: read_block: read error: Invalid packet
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0

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
attached trivial patch of g10/import.c. It allows the import to succeed
with the "signature packet: hashed data too long" warning.

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
invalid imported public key?).

Maybe someone with more insight into the matter can also think of other
possible DoS scenarios, like other maliciously large packet types or
similar, which should additionally be handled at this point of the
code.

Please consider applying the patch upstream or making equivalent changes
to the code, to get GnuPG more DoS resistant in the future.

Thank you,
Robert

Re: [PATCH gnupg] g10/import.c: ignore too large signature packets [ In reply to ]

gnupg-devel at lists

Apr 22, 2022, 11:40 AM

Post #2 of 4 (544 views)

Permalink

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.

> 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.

> 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.

Salam-Shalom,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

Re: [PATCH gnupg] g10/import.c: ignore too large signature packets [ In reply to ]

gnupg-devel at lists

Apr 23, 2022, 2:43 AM

Post #3 of 4 (540 views)

Permalink

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.

Re: [PATCH gnupg] g10/import.c: ignore too large signature packets [ In reply to ]

gnupg-devel at lists

Apr 25, 2022, 11:53 AM

Post #4 of 4 (533 views)

Permalink

On Sat, 23 Apr 2022 11:43, Robert Bartel said:
> 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.

For my key I had to resort to configs like this

import-filter drop-sig= sig_created_d=2015-12-24
import-filter drop-sig=|| sig_created_d=2001-01-01

:-(

Shalom-Salam,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

Mailing List Archive

Attached Files:

Attached Files:

Attached Files:

Attached Files: