Re: Many vulnerabilities in GnuPG

[Solar Designer <solar () openwall com>]

On Sat, Dec 27, 2025 at 07:29:53PM -0500, Demi Marie Obenour wrote:
> https://gpg.fail lists many vulnerabilities in GnuPG, one of which
> allows remote code execution.  All are zero-days to the best of
> my knowledge.

Thanks.  I wish this were brought in here by the researchers, but since
it was not and since we require actual content here (not just links),
let me take care of this now.  The website has it nicely formatted, so I
also include the HTML versions, which brings the message to just below
the maximum of 1 MiB here.  Who knows how long this website will stay
up, but oss-security archives will probably exist decades later.

The website currently says:

>                          Slides, pocs and patches soon!
>
>    "in the hurry of leaving i forgot the sites src at home, sorry, had to
>    rewrite the whole thing. expect a nicer site by tomorrow. im patching as
>    we speak."
>    - crackticker (<- to blame)
>
>     1. Multiple Plaintext Attack on Detached PGP Signatures in GnuPG
>     2. GnuPG Accepts Path Separators and Path Traversals in Literal Data
>        "Filename" Field
>     3. Cleartext Signature Plaintext Truncated for Hash Calculation
>     4. Encrypted message malleability checks are incorrectly enforced causing
>        plaintext recovery attacks
>     5. Memory Corruption in ASCII-Armor Parsing
>     6. Trusted comment injection (minisign)
>     7. Cleartext Signature Forgery in the NotDashEscaped header
>        implementation in GnuPG
>     8. OpenPGP Cleartext Signature Framework Susceptible to Format Confusion
>     9. GnuPG Output Fails To Distinguish Signature Verification Success From
>        Message Content
>    10. Cleartext Signature Forgery in GnuPG
>    11. Radix64 Line-Truncation Enabling Polyglot Attacks
>    12. GnuPG may downgrade digest algorithm to SHA1 during key signature
>        checking
>    13. GnuPG Trust Packet Parsing Enables Adding Arbitrary Subkeys
>    14. Trusted comment Injection (minisign)

Each of the above 14 vulnerabilities has its own web page.  I attach 14
text (converted with ELinks at width 80) and 14 HTML files corresponding
to them.

Also included on the website is the talk video (49 minutes).

This disclosure was part of the below 39C3 talk:

https://fahrplan.events.ccc.de/congress/2025/fahrplan/event/to-sign-or-not-to-sign-practical-vulnerabilities-i

> To sign or not to sign: Practical vulnerabilities in GPG & friends
> Day 1  17:15  One  en  Security
> Dec. 27, 2025 17:15-18:15
>
> Might contain zerodays. https://gpg.fail/ From secure communications to
> software updates: PGP implementations such as *GnuPG* ubiquitously
> relied on to provide cryptographic assurances. Many applications from
> secure communications to software updates fundamentally rely on these
> utilities. Since these have been developed for decades, one might expect
> mature codebases, a multitude of code audit reports, and extensive
> continuous testing. When looking into various PGP-related codebases for
> some personal use cases, we found these expectations not met, and
> discovered multiple vulnerabilities in cryptographic utilities, namely
> in *GnuPG*, *Sequoia PGP*, *age*, and *minisign*. The vulnerabilities
> have implementation bugs at their core, for example in parsing code,
> rather than bugs in the mathematics of the cryptography itself. A
> vulnerability in a parser could for example lead to a confusion about
> what data was actually signed, allowing attackers without the private
> key of the signer to swap the plain text. As we initially did not start
> with the intent of conducting security research, but rather were looking
> into understanding some internals of key management and signatures for
> personal use, we also discuss the process of uncovering these bugs.
> Furthermore, we touch on the role of the OpenPGP specification, and the
> disclosure process.
>
> Beyond the underlying mathematics of cryptographic algorithms, there is
> a whole other layer of implementation code, assigning meaning to the
> processed data. For example, a signature verification operation both
> needs robust cryptography and assurance that the verified data is indeed
> the same as was passed into the signing operation. To facilitate the
> second part, software such as GnuPG implement parsing and processing
> code of a standardized format. Especially when implementing a feature
> rich and evolving standard, there is the risk of ambivalent
> specification, and classical implementation bugs.
>
> The impact of the vulnerabilities we found reaches from various
> signature verification bypasses, breaking encryption in transit and
> encryption at rest, undermining key signatures, to exploitable memory
> corruption vulnerabilities.
>
> Speakers of this event
> 49016 does many computer adjacent things; it has a talent for breaking
> them, and occasionally does security research for good in its free time.
>
> Liam is motivated by understanding programs in depth: taking a program
> that runs and making it dance.

Alexander

Attachment: 01-detached.txt
Description:

Attachment: 02-filename.txt
Description:

Attachment: 03-formfeed.txt
Description:

Attachment: 04-malleability.txt
Description:

Attachment: 05-memcpy.txt
Description:

Attachment: 06-minisign.txt
Description:

Attachment: 07-notdash.txt
Description:

Attachment: 08-notsoclear.txt
Description:

Attachment: 09-noverify.txt
Description:

Attachment: 10-nullbyte.txt
Description:

Attachment: 11-polyglot.txt
Description:

Attachment: 12-sha1.txt
Description:

Attachment: 13-trust.txt
Description:

Attachment: 14-trustcomment.txt
Description: