Re: Many vulnerabilities in GnuPG

[Werner Koch <wk () gnupg org>]

Hi!

Jacob was so kind to comment on the reported bugs.  I agree with most of
his comments.  Please let me point you also to
https://dev.gnupg.org/T7900 which is the parent ticket for all these
reports.  We received them in October one after the other and then
compiled this list of tickets.

Because there was no clear statement on when we were allowed to publish
them and no further communication, most of them were set to private.  I
set them to public when I noticed the schedule for the talk on December
26.  At that time I also drafted an article to explain the well known
prblem of hard-to-correct-use of cleartext signatures including a bit of
history: https://gnupg.org/blog/20251226-cleartext-signatures.html

> Item 5: Memory Corruption in ASCII-Armor Parsing
>
> This is a serious memory-safety error in GPG.

Yes, and actually the only serious bug from their list.  This one
(T7906) was fixed in the repo on November 4 (T7906) and released with
2.5.14 on 2025-11-19:

  * gpg: Fix possible memory corruption in the armor parser.  [T7906]

and in the ExtendedLTS version 2.2.51 already on: 2025-10-28:

  * gpg: Fix possible memory corruption in the armor parser.
    [rG1e929abd20]

Another release of 2.4 is still pending but given that its end-of-life is
in 6 months, it would anyway better to switch to 2.5.

Whether this bug is really exploitable is still questionable but of
course we decided to fix that.  Thus the claim by Demi Marie "one of
which allows remote code execution.  [All are zero-days to the best of
my knowledge.]" is over the top.  Even the report marks this bug as a
"may":

   Impact
   While this may allow remote code execution (RCE), it definitively
   causes memory corruption.

Good research.

> Item 7: Cleartext Signature Forgery in the NotDashEscaped header
> implementation in GnuPG
>
> This is a misfeature that probably should not have been implemented,
> or should have been implemented much more strictly.

Right.  I did not mentioned it in my blog to keep it readable.  My
comment in the tcket (T7901):

  I agree because the original purpose from the 90ies to enable the use
  of signed patch files in the Linux kernel community was never actually
  used and GnuPG stopped the distribution of patches from version to
  version many years ago. Thus I agree we should hide this option behind
  a compatibility flag.

This proposed flag has not yet been implemented but nevertheless the
same reasoning as for all other cleartext signatures holds here.

> Item 12: GnuPG may downgrade digest algorithm to SHA1 during key
> signature checking

This is T7904.

> The root of this is another out-of-bounds read. There is a simple fix
> to this: always, *always*, *ALWAYS* initialize stack-resident local
> variables.

Which is sometimes not good because it inbits compiler checks.
Anyway, good catch and was fixed on November 4.

> I am also unsure about the actual insecurity of SHA1 in general. Have
> there been more attacks since the first actual collision?

For an exploit you need to have a 2nd preimage attack on SHA1 on this
very data structure which has not yet been found.  

> Item 13: GnuPG Trust Packet Parsing Enables Adding Arbitrary Subkeys

That reported exploit requires social engineering to force the user to
modify GnuPG local data stuctures.



Shalom-Salam,

   Werner


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

Attachment: openpgp-digital-signature.asc
Description: