Re: [oss-security] Many vulnerabilities in GnuPG

[Stephan Verbücheln]

On Tue, 2025-12-30 at 00:34 -0600, Jacob Bachmeyer wrote:
> I am not sure about that.  As I understand, OpenPGP (and Git, for 
> another example) only needs second preimage resistance, unlike X.509 
> which needs absolute collision resistance, and the closest attack on 
> SHA-1 is still only a chosen-prefix collision.
> 
> The SHA-1 sky has not fallen, yet.  It may be getting a bit creaky,
> but it is not falling.  :-)  (Yet...)  :-/

For certifications (aka key signatures), SHA-1 should be considered
insecure. An attacker could generate two identities with the same SHA-1
hash and then let people sign one of them.

Regards


signature.asc
Description: This is a digitally signed message part

Re: [oss-security] Many vulnerabilities in GnuPG

[Peter Gutmann]

Henrik Ahlgren  writes:

>Perhaps the Debian developer keyring would serve as a compelling example?
>They even organize actual key-signing parties, which many cryptography
>experts today appear to regard as "LARPing" or otherwise ridiculous.

That sounds almost exactly like a CA key signing ceremony rather than any kind
of WoT thing...

Peter.

Re: [oss-security] Many vulnerabilities in GnuPG

[Jeffrey Walton]

On Tue, Dec 30, 2025 at 11:54 PM Demi Marie Obenour
 wrote:
>
> On 12/29/25 11:57, Lexi Groves (49016) wrote:
> > Hi! Thanks for the comment. Some clarifications from us:
>
> (snip)
>
> >  > > Given a signed document, you can either check the signature or
> > check the signature and recover the original document. To check the
> > signature use the --verify option. To verify the signature and extract
> > the document use the --decrypt option. The signed document to verify and
> > recover is input and the recovered document is output.

At the risk of splitting hairs (I did not see someone else point it out):

  1. "check the signature" - signature scheme with appendix (SSA)
  2. "check the signature and recover the original document" -
signature scheme with recovery (SSR)

SSA (item 1) requires two objects -- the original document and the
signature.  The verification process needs both the document and the
signature objects.  A detached signature scheme is a SSA.

SSR (Item 2) requires one object -- the signature over the document.
The verification process can extract the original document.  This is
sometimes (usually?) what people mean when they say "encrypt with the
private key".

> >  > > ```
> >  > > blake% gpg --output doc --decrypt doc.sig
> >  > > gpg: Signature made Fri Jun  4 12:02:38 1999 CDT using DSA key ID
> > BB7576AC
> >  > > gpg: Good signature from "Alice (Judge) "
> >  > > ```
> >
> > We assumed that the manual was the source of truth and assumed that
> > using `--decrypt` was the standard way to do this; we may have been
> > biased here, because apparently the common knowledge about this
> > (according to some other documentation that we did not see) was using
> > `--output/-o`. However, due to the nature of the attack, setting the
> > wrong output file while hashing the correct file, `--output` works the
> > same way:
> >
> > ```
> > $ gpg --output x --verify msg.txt.sig msg.txt
> > gpg: Signature made Mon 29 Dec 2025 02:59:11 PM CET
> > gpg:using EDDSA key EE6EADB4CBB063887A3BE2B413AEBEC571BA1447
> > gpg: Good signature from "39c3 demo " [ultimate]
> > $ cat msg.txt
> > asdf
> > $ cat x
> > Malicious
> > ```
>
> Does this work with 'gpgv'?
>
> I think most software update tools use `msg.txt` directly and so are
> not vulnerable, *unless* the signature uses text mode in which case
> a different attack might work.  Can you see if APT is vulnerable?

For completeness, the scheme Debian and APT use is documented in the
Debian manual.  See Section 7.5.1 at
.

Jeff

Re: [oss-security] Many vulnerabilities in GnuPG

[Jacob Bachmeyer]

On 12/29/25 18:57, Peter Gutmann wrote:

[...]

A solution for mission-critical use like authenticating downloaded binaries
would be to do two things:

1. Create an app that does just that and nothing else: Here is a blob of data,
here is a detached signature, is it valid for the data?


Does using gpgv(1) with detached signatures fit this bill?

I am unsure what having a separate tool dedicated for verifying 
signatures using trusted keyrings says about the overall system...



-- Jacob

Re: [oss-security] Many vulnerabilities in GnuPG

[Collin Funk]

Henrik Ahlgren  writes:

> Peter Gutmann  writes:
>
>> Does anything actually use the cobweb of trust, or do you just assume the key
>> you've got is good because doing anything else is too hard?
>
> Perhaps the Debian developer keyring would serve as a compelling
> example? They even organize actual key-signing parties, which many
> cryptography experts today appear to regard as "LARPing" or otherwise
> ridiculous.

Or the Linux kernel [1].

Collin

[1] 
https://www.kernel.org/doc/html/v6.19-rc2/process/maintainer-pgp-guide.html#using-the-kernel-org-web-of-trust-repository

Re: [oss-security] Many vulnerabilities in GnuPG

[Henrik Ahlgren]

Peter Gutmann  writes:

> Does anything actually use the cobweb of trust, or do you just assume the key
> you've got is good because doing anything else is too hard?

Perhaps the Debian developer keyring would serve as a compelling
example? They even organize actual key-signing parties, which many
cryptography experts today appear to regard as "LARPing" or otherwise
ridiculous.

Re: [oss-security] Many vulnerabilities in GnuPG

[Sam James]

Demi Marie Obenour  writes:

> On 12/29/25 11:57, Lexi Groves (49016) wrote:
> [...]
>>  > Item 5:  Memory Corruption in ASCII-Armor Parsing
>>  >
>>  > This is a serious memory-safety error in GPG.
>> 
>> Yes. We did not have the time to try to exploit it, but we agreed that 
>> there is potential for remote code execution. We think that it is 
>> irresponsible to not release the fix on the 2.4 branch, which is what 
>> most users in the wild use.
>
> I totally agree.  This is why I referred to this vulnerability as
> a zero-day.
>
> (snip)

It's fixed in gnupg-2.4.9 for that branch, released today.

Re: [oss-security] Many vulnerabilities in GnuPG

[Peter Gutmann]

Demi Marie Obenour writes:

>Can we agree to use OpenSSH signatures ASAP?

PGP signatures are fine, for authenticating binaries we just need to use them
in a way where there's only one simple, unambiguous, and minimal-attack-
surface way to apply them, as well as a means of having them work over longer
time periods (see below).  The alternative is to try to boil the ocean, which
would take a Heartbleed-style catastrophe to motivate.

>Interesting!  Which ones don't work?

I'm using it to generate test data which will no doubt trigger odd behaviour
in some cases, and didn't record info about individual problems, just "type
this command to get this output" once I figured out what was required.  An
example is:

  gpg -b -z 0 --openpgp --homedir . -o signed4.pgp test.txt

  (the --openpgp is for a GPG bug, without it it'll generate v3 sigs as if
   --force-v3-sigs had been specified).

but for most of them all I've recorded is just whatever magic incantation
eventually worked to generate the required test data.

>Is that what gpgv and sqv are?

It depends on how much of the rest of GPG is still present.  If it's just a
stripped-down front-end to the whole thing then it may still be subject to the
same vulns.

>I think the hard part of doing this isn't the signature handling itself, but
>rather the incredibly complex web of trust.

Does anything actually use the cobweb of trust, or do you just assume the key
you've got is good because doing anything else is too hard?  Certainly for
authenticating Linux installs and updates the practice seems to be "grab the
key from this source via TLS, swear a lot because it's KEYEXPIRED, spend ages
Googling how to get the latest key, realise you have to install intermediate
updates to work your way up to what's current but the only remaining source
for those is a server in Botswana and all the apt options have changed and you
need to read a garbled blog post someone wrote at 3am when they ran into the

[ 25 more lines of pain snipped ]

just run with --allow-unauthenticated and ensuing zero security so you can
finally update your stuff before you die of old age".  That's one thing
Microsoft did well with Authenticode, you don't get all your updates blocked
because your valid keys instantly became invalid after some timer ticked past
midnight.

>>I've actually done something like this myself, wrote simple apps pgpencrypt
>>and pgpdecrypt (size around 50kB)
>
>Are these available anywhere?

They're just some very quick things I threw together ten or more years ago,
motivated by:

/* Used to decrypt files that the four assorted command-line versions of PGP
   can't handle */

(this was before GPG became the de facto universal standard).  I can send you
the code privately if you like, but it probably won't be very useful.

>Yeah, that's *embarrassing*.

I wouldn't say it's embarrassing, more that it's a confirmation of Shamir's
Law, "crypto is bypassed, not attacked".  To find the biggest holes in a
crypto app you need a pentester, not a cryptographer.

Peter.

Re: [oss-security] Many vulnerabilities in GnuPG

[Demi Marie Obenour]

On 12/29/25 11:57, Lexi Groves (49016) wrote:
> Hi! Thanks for the comment. Some clarifications from us:

(snip)

>  > > Given a signed document, you can either check the signature or 
> check the signature and recover the original document. To check the 
> signature use the --verify option. To verify the signature and extract 
> the document use the --decrypt option. The signed document to verify and 
> recover is input and the recovered document is output.
>  > >
>  > > ```
>  > > blake% gpg --output doc --decrypt doc.sig
>  > > gpg: Signature made Fri Jun  4 12:02:38 1999 CDT using DSA key ID 
> BB7576AC
>  > > gpg: Good signature from "Alice (Judge) "
>  > > ```
> 
> We assumed that the manual was the source of truth and assumed that 
> using `--decrypt` was the standard way to do this; we may have been 
> biased here, because apparently the common knowledge about this 
> (according to some other documentation that we did not see) was using 
> `--output/-o`. However, due to the nature of the attack, setting the 
> wrong output file while hashing the correct file, `--output` works the 
> same way:
> 
> ```
> $ gpg --output x --verify msg.txt.sig msg.txt
> gpg: Signature made Mon 29 Dec 2025 02:59:11 PM CET
> gpg:                using EDDSA key EE6EADB4CBB063887A3BE2B413AEBEC571BA1447
> gpg: Good signature from "39c3 demo " [ultimate]
> $ cat msg.txt
> asdf
> $ cat x
> Malicious
> ```

Does this work with 'gpgv'?

I think most software update tools use `msg.txt` directly and so are
not vulnerable, *unless* the signature uses text mode in which case
a different attack might work.  Can you see if APT is vulnerable?

(snip)

>  > Item 5:  Memory Corruption in ASCII-Armor Parsing
>  >
>  > This is a serious memory-safety error in GPG.
> 
> Yes. We did not have the time to try to exploit it, but we agreed that 
> there is potential for remote code execution. We think that it is 
> irresponsible to not release the fix on the 2.4 branch, which is what 
> most users in the wild use.

I totally agree.  This is why I referred to this vulnerability as
a zero-day.

(snip)

>  > Item 9:  GnuPG Output Fails To Distinguish Signature Verification 
> Success From Message Content
>  >
>  > I think this is actually an old problem, previously affecting 
> Thunderbird and Git IIRC, and the existing --status-fd mechanism in GPG 
> is meant for exactly this case, at least for automated processing.
> 
> The general concept yes, we just found that in practice `--verify` just 
> does not work with encrypted and signed payloads, which further makes 
> this harder to avoid on the CLI specifically.

Also GnuPG does not fail on the first write error to the status
line unless --exit-on-status-write-error is passed.  Even then,
some errors are not handled properly and can cause corrupt output
(possibly right before an exit).
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [oss-security] Many vulnerabilities in GnuPG

[Demi Marie Obenour]

On 12/29/25 19:57, Peter Gutmann wrote:
> Stephan Verbücheln writes:
> 
>> The overall status is not good though.
> 
> I'm more concerned about a slightly different aspect, that two researchers
> (apparently) walked up to GPG and quickly found a pile of bugs, many relating
> to authentication [0].  OpenPGP sigs are the de facto universal standard for
> authenticating code and binaries in the non-Windows world, the equivalent of
> Windows Authenticode, and GPG is the tool that's used for that.  The one with
> all the bugs in its authentication handling.

I agree.  Can we agree to use OpenSSH signatures ASAP?  Those actually
are decently designed, though I do wish that they had the ability
to include structured metadata.  One could abuse the "reserved"
field for this, though.  Of course, it should only be parsed after
verifying the signature.

> There are two issues that cause this, the first being that GPG is staggeringly
> complex.  It's not a sign-and-encrypt app any more but an entire suite that
> runs daemons/services, spawns off subprograms, creates and uses a ton of files
> in its own proprietary data formats, and has a million command-line options
> that change across releases (I use it for generating OpenPGP test vectors so I
> get to try lots of options that, by the looks of it, no-one else uses because
> some of them function other than expected or not at all).

Interesting!  Which ones don't work?

> The second one is the format, best summed up by Thomas Ptacek's comment at
> https://news.ycombinator.com/item?id=46404339 which begins:
> 
>   A thru-line of some of the gnarliest vulnerabilities here is PGP's insane
>   packet system, where a PGP message is a practically arbitrary stream of
>   packets, some control and some data, with totally incoherent cryptographic
>   bindings. It's like something in between XMLDSIG (which pulls cryptographic
>   control data out of random places in XML messages according to attacker-
>   controlled tags) and SSL2 (with no coherent authentication of the complete
>   handshake).
> 
> For an example of this, consider compressed signed data, so you've got an EDI
> transaction that you want to compress (it's a large blob of fixed-format text)
> and then sign.  With CMS (Cryptographic Message Syntax) you get:
> 
>   Sign( Compress( Message ) )
> 
> With OpenPGP it's a crapshoot.  You'd expect something like the above but what
> GPG does is:
> 
>   Compress( One-pass Sig || Message || Signature )
> 
> which is valid but pretty unexpected.  And then any application needs to have
> complex and awkward logic to process these things as per tptacek's comment.

Sequoia actually uses a full parser generator (LALRPOP) to deal with
this.That is the only reasonable approach I know of.  Incidentally,
this should also be able to handle CMS just fine.  The only caveat
is the parser needs to be able to tell the lexer to return a single
token for a certificate or CRL, and that requires an ugly lexer hack
that depends on the parser not reading too many tokens ahead of time.

> To appreciate just how bad it really is, grab a copy of RFC 9580 and see how
> long it takes you to write down the sequence of fields (not packets, fields)
> that you'd expect to see in a message encrypted with RSA and signed with
> Ed25519 (to grab the two opposite ends of the cryptographic spectrum) as well
> as the cryptographic bindings between them, i.e. which bits get hashed/signed/
> processed, and also provide a confidence level in your work.  I suspect most
> people won't even get to that, the answer would be "I can't figure it out".
> 
> A solution for mission-critical use like authenticating downloaded binaries
> would be to do two things:
> 
> 1. Create an app that does just that and nothing else: Here is a blob of data,
> here is a detached signature, is it valid for the data?

Is that what gpgv and sqv are?  I think the hard part of doing this
isn't the signature handling itself, but rather the incredibly complex
web of trust.  Detached signatures seem to be the only semi-reasonable
part of OpenPGP.

> 2. Define a fixed format for Authenticode-style signatures in OpenPGP form
> that allows one and only one agglutination of OpenPGP packets and fields in
> packets that are considered a valid signature.

I actually did that myself as part of
.  The OpenPGP parser built
in to RPM wasn't something I wanted to expose to untrusted input, and
the RPM version in Qubes OS dom0 was end of life.  I added a validator
that checked for the only expected format: one signature packet.

I haven't looked much into how OpenPGP encryption works and I agree
that it's a much worse mess.

> I've actually done something like this myself, wrote simple apps pgpencrypt
> and pgpdecrypt (size around 50kB) that do exactly what the name says and
> nothing else so I don't have to remember a million command-line options and
> deal with a pile of files and settings.  It's just "

Re: [oss-security] Many vulnerabilities in GnuPG

[Jacob Bachmeyer]

On 12/29/25 10:57, Lexi Groves (49016) wrote:

Hi! Thanks for the comment. Some clarifications from us:

> Overall, I have one very major point of disagreement here: the 
OpenPGP clearsign format is useful precisely because it enables the 
signed message to be easily viewed with other tools, thus complicating 
attacks and making large-scale attacks much more likely to be 
detected.  (It only takes one user who looks at a clearsigned digest 
list with less(1) and sees a bunch of control sequences to raise an 
alarm.)


This affects two of the vulnerabilities, and while we do agree that we 
focused exploitation on naive viewers, one can also leave out the 
"creative formatting"; especially the `NotDashEscaped:` header can 
also be used without any control sequences. These two specific attacks 
do have their limitations, but are still worth reporting.


I agree that they are worth reporting, but I am not yet convinced that 
they are fatal flaws in the OpenPGP clearsign format.



> Item 1:  Multiple Plaintext Attack on Detached PGP Signatures in GnuPG
>
> Exploitation requires a very odd use of signatures.  Bob knows that 
he has a detached signature, and ordinarily a detached signature is 
simply used to verify the signed file, after which the signed file is 
used directly.


This was found especially in response to the clearsig advice being to 
use an option to print what was *actually* verified, e.g. `--decrypt`, 
to avoid plaintext confusion attacks. This fools exactly that 
mechanism that was used to prevent exploitation in the previous attacks.


In other words, the correct ways to verify a detached signature and a 
clearsigned message are different.  Since which of those you should have 
is obvious, that is only a matter of user education.



[...]

We assumed that the manual was the source of truth and assumed that 
using `--decrypt` was the standard way to do this; we may have been 
biased here, because apparently the common knowledge about this 
(according to some other documentation that we did not see) was using 
`--output/-o`. However, due to the nature of the attack, setting the 
wrong output file while hashing the correct file, `--output` works the 
same way:


```
$ gpg --output x --verify msg.txt.sig msg.txt
gpg: Signature made Mon 29 Dec 2025 02:59:11 PM CET
gpg:                using EDDSA key 
EE6EADB4CBB063887A3BE2B413AEBEC571BA1447

gpg: Good signature from "39c3 demo " [ultimate]
$ cat msg.txt
asdf
$ cat x
Malicious
```


Now that I look at this again, I see a logic error in GPG:  GPG *should* 
barf if directed to verify a detached signature (which it knows because 
it was given the name of the file to verify on the command line) but the 
"detached signature" contains a message in the OpenPGP packet stream.


There is another logic error here also:  GPG can be tricked into 
emitting output that is *not* the signed message.  Do I now understand 
correctly that GPG will *verify* the original signature but *output* the 
contents of the injected Literal Packet?


In other words, there is a workaround for careful users:  use 
`--decrypt`/`--output` *only* when reading a signed message, and only 
`--verify` when checking a detached signature.  Is this correct?



[...]

> Item 2:  GnuPG Accepts Path Separators and Path Traversals in 
Literal Data "Filename" Field

>
> While this is a potentially serious bug, as it enables an attacker 
to potentially overwrite any file if the attacker can guess the file 
name, it also relies more on a social-engineering attack.  While a 
naive user might use the suggested command, a more-experienced user 
should immediately smell a rat.


Yes. This probably wouldn't fool a hardcore cypherpunk, but to be 
honest, it'd get me. Reaper compared this to a clickjacking attack in 
web exploitation, and we completely agree with this classification: 
this is an exploit chain that abuses the naivety of the user to 
trigger a *technical* issue.  Nevertheless, I believe that software 
should always do its best to protect against human error.


I agree that GPG should force extracted files visibly into the current 
directory unless explicitly directed otherwise.  This is logically easy 
on POSIX:  s!/!_!g and s!^[.]!_! on the filename. Of course, if the user 
specifies `--output` then write to exactly the name given.


> The PoC uses ANSI escapes to cover up (erase, move left) the hash 
mark that makes the fake message viable as a shell script, the actual 
payload command (set as invisible text), and the prompt from GPG about 
writing the output file (which appears to be sent to the window 
title).  I am uncertain how the user is supposed to see the next 
prompt, as the invisible text mode does not appear to be reset.


This was a slight miscommunication; this does indeed swallow the next 
bash prompt. Assuming a user doesn't then recover their terminal but 
just restarts the shell, it spawns a new Bash process, which sources 
the newly written file. This was just one exam

Re: [oss-security] Many vulnerabilities in GnuPG

[Alan Coopersmith]

On 12/29/25 01:15, Stephan Verbücheln wrote:

GnuPG follows a traditional versioning scheme where even numbers (e.g.
2.2 and 2.4) are release branches and odd numbers (2.3 and 2.5) are
developer branches. So what we have to wait for is 2.4.9 fixing the
vulnerabilities.


Is that still true?

https://gnupg.org/ states:

  Note that the 2.5 series is now declared the stable version of GnuPG.
  Be aware that the oldstable 2.4 series will reach end-of-life in just
  6 months.

--
-Alan Coopersmith- alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Re: [oss-security] Many vulnerabilities in GnuPG

[Demi Marie Obenour]

On 12/29/25 04:51, Werner Koch wrote:
>> 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.

I wasn't aware of the fix commits.  The fixed bugs are indeed
not zero-day vulnerabilities from an upstream perspective.
They are, however, zero-day vulnerabilities for many distro users.
In particular, Fedora 42, 43, and Rawhide do not have the fixes.

While upstream did use the word "may", it also states:

> From here it is a challenge in memory corruption exploitation
> with a very large space of reachable primitives.

I concluded from this that exploitation is just a matter of effort.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [oss-security] Many vulnerabilities in GnuPG

[Peter Gutmann]

Stephan Verbücheln writes:

>The overall status is not good though.

I'm more concerned about a slightly different aspect, that two researchers
(apparently) walked up to GPG and quickly found a pile of bugs, many relating
to authentication [0].  OpenPGP sigs are the de facto universal standard for
authenticating code and binaries in the non-Windows world, the equivalent of
Windows Authenticode, and GPG is the tool that's used for that.  The one with
all the bugs in its authentication handling.

There are two issues that cause this, the first being that GPG is staggeringly
complex.  It's not a sign-and-encrypt app any more but an entire suite that
runs daemons/services, spawns off subprograms, creates and uses a ton of files
in its own proprietary data formats, and has a million command-line options
that change across releases (I use it for generating OpenPGP test vectors so I
get to try lots of options that, by the looks of it, no-one else uses because
some of them function other than expected or not at all).

The second one is the format, best summed up by Thomas Ptacek's comment at
https://news.ycombinator.com/item?id=46404339 which begins:

  A thru-line of some of the gnarliest vulnerabilities here is PGP's insane
  packet system, where a PGP message is a practically arbitrary stream of
  packets, some control and some data, with totally incoherent cryptographic
  bindings. It's like something in between XMLDSIG (which pulls cryptographic
  control data out of random places in XML messages according to attacker-
  controlled tags) and SSL2 (with no coherent authentication of the complete
  handshake).

For an example of this, consider compressed signed data, so you've got an EDI
transaction that you want to compress (it's a large blob of fixed-format text)
and then sign.  With CMS (Cryptographic Message Syntax) you get:

Sign( Compress( Message ) )

With OpenPGP it's a crapshoot.  You'd expect something like the above but what
GPG does is:

Compress( One-pass Sig || Message || Signature )

which is valid but pretty unexpected.  And then any application needs to have
complex and awkward logic to process these things as per tptacek's comment.

To appreciate just how bad it really is, grab a copy of RFC 9580 and see how
long it takes you to write down the sequence of fields (not packets, fields)
that you'd expect to see in a message encrypted with RSA and signed with
Ed25519 (to grab the two opposite ends of the cryptographic spectrum) as well
as the cryptographic bindings between them, i.e. which bits get hashed/signed/
processed, and also provide a confidence level in your work.  I suspect most
people won't even get to that, the answer would be "I can't figure it out".

A solution for mission-critical use like authenticating downloaded binaries
would be to do two things:

1. Create an app that does just that and nothing else: Here is a blob of data,
here is a detached signature, is it valid for the data?

2. Define a fixed format for Authenticode-style signatures in OpenPGP form
that allows one and only one agglutination of OpenPGP packets and fields in
packets that are considered a valid signature.

I've actually done something like this myself, wrote simple apps pgpencrypt
and pgpdecrypt (size around 50kB) that do exactly what the name says and
nothing else so I don't have to remember a million command-line options and
deal with a pile of files and settings.  It's just "pgpencrypt file", and
there's little facility to perform attacks like in the talk because there's no
extra capabilities there to attack.

As an aside, did anyone notice the problem in the code snippet on slide 91 of
the talk?  It looks like they've paraphrased but typo'd the original code,
which correctly uses | instead of &.

Peter.

[0] The talk doesn't cover how much effort was involved, the speakers mention
they're not cryptographers but pen-testers so no crypto knowledge was
required.

Re: [oss-security] Many vulnerabilities in GnuPG

[Sam James]

Henrik Ahlgren  writes:

> "Lexi Groves (49016)"  writes:
>
>> Yes. We found this advice in [The GNU Privacy Handbook, Chapter 1.
>> Getting Started, Making and verifying
>> signatures](https://www.gnupg.org/gph/en/manual/x135.html):
>
> I'd just like to point out that the GNU Privacy Handbook (GPH) was
> published in 1999, and I have not encountered any more recent revisions.

I got this impression but couldn't find anything specifically saying it
was archived.

I filed a bug earlier and included https://dev.gnupg.org/T7993#210212
for one issue in it, but if it's not been revised since, perhaps it
should be archived with a banner on each page or something, as it's
readily found via search engines at the moment.

> I believe GnuPG did not even support RSA until version 1.0.3 and
> AES/Rijndael until version 1.0.4, which were released in 2000, meaning
> the handbook exclusively addresses DSA and ElGamal, making it 25 years
> out of date.

The GnuPG versions in the output got me suspicious enough ;)

>
> The GnuPG Manual (https://gnupg.org/documentation/manuals/gnupg/) is
> much more current, but sadly it is not structured as a user guide that
> would introduce a new user to PGP concepts and best practices, etc.

sam

Re: [oss-security] Many vulnerabilities in GnuPG

[Henrik Ahlgren]

"Lexi Groves (49016)"  writes:

> Yes. We found this advice in [The GNU Privacy Handbook, Chapter 1.
> Getting Started, Making and verifying
> signatures](https://www.gnupg.org/gph/en/manual/x135.html):

I'd just like to point out that the GNU Privacy Handbook (GPH) was
published in 1999, and I have not encountered any more recent revisions.
I believe GnuPG did not even support RSA until version 1.0.3 and
AES/Rijndael until version 1.0.4, which were released in 2000, meaning
the handbook exclusively addresses DSA and ElGamal, making it 25 years
out of date.

The GnuPG Manual (https://gnupg.org/documentation/manuals/gnupg/) is
much more current, but sadly it is not structured as a user guide that
would introduce a new user to PGP concepts and best practices, etc.

Re: [oss-security] Many vulnerabilities in GnuPG

[Lexi Groves (49016)]

Hi! Thanks for the comment. Some clarifications from us:

> Overall, I have one very major point of disagreement here: the 
OpenPGP clearsign format is useful precisely because it enables the 
signed message to be easily viewed with other tools, thus complicating 
attacks and making large-scale attacks much more likely to be detected.  
(It only takes one user who looks at a clearsigned digest list with 
less(1) and sees a bunch of control sequences to raise an alarm.)


This affects two of the vulnerabilities, and while we do agree that we 
focused exploitation on naive viewers, one can also leave out the 
"creative formatting"; especially the `NotDashEscaped:` header can also 
be used without any control sequences. These two specific attacks do 
have their limitations, but are still worth reporting.


> Item 1:  Multiple Plaintext Attack on Detached PGP Signatures in GnuPG
>
> Exploitation requires a very odd use of signatures.  Bob knows that 
he has a detached signature, and ordinarily a detached signature is 
simply used to verify the signed file, after which the signed file is 
used directly.


This was found especially in response to the clearsig advice being to 
use an option to print what was *actually* verified, e.g. `--decrypt`, 
to avoid plaintext confusion attacks. This fools exactly that mechanism 
that was used to prevent exploitation in the previous attacks.


> This is also the first time I have seen --decrypt suggested for 
reading a signed message; does this also work if the message is encrypted?


Yes. We found this advice in [The GNU Privacy Handbook, Chapter 1. 
Getting Started, Making and verifying 
signatures](https://www.gnupg.org/gph/en/manual/x135.html):


> > Given a signed document, you can either check the signature or 
check the signature and recover the original document. To check the 
signature use the --verify option. To verify the signature and extract 
the document use the --decrypt option. The signed document to verify and 
recover is input and the recovered document is output.

> >
> > ```
> > blake% gpg --output doc --decrypt doc.sig
> > gpg: Signature made Fri Jun  4 12:02:38 1999 CDT using DSA key ID 
BB7576AC

> > gpg: Good signature from "Alice (Judge) "
> > ```

We assumed that the manual was the source of truth and assumed that 
using `--decrypt` was the standard way to do this; we may have been 
biased here, because apparently the common knowledge about this 
(according to some other documentation that we did not see) was using 
`--output/-o`. However, due to the nature of the attack, setting the 
wrong output file while hashing the correct file, `--output` works the 
same way:


```
$ gpg --output x --verify msg.txt.sig msg.txt
gpg: Signature made Mon 29 Dec 2025 02:59:11 PM CET
gpg:                using EDDSA key EE6EADB4CBB063887A3BE2B413AEBEC571BA1447
gpg: Good signature from "39c3 demo " [ultimate]
$ cat msg.txt
asdf
$ cat x
Malicious
```

> Mallory can be assumed to have Bob's public key and could therefore 
generate a second encrypted message to Bob if Alice's message was signed 
and encrypted.  There would be an interesting indicator of compromise:  
an abnormally-large detached signature.


Yes. That is indeed one way to spot this attack in suboptimal 
conditions, but when a small signature is needed (e.g. over a digest of 
an ISO), and with the varying lengths between signatures like Ed25519 
and RSA4k+, this can be exploited realistically.


> This exposes *another* bug in GPG:  documentation says that --decrypt 
will reject an unencrypted input, yet the PoC involves using it with 
exactly that.


This is actually news to us as well, but yes, apparently `--decrypt` is 
not supposed to do that. Please assume that we wanted a "print what was 
verified" option, and our attacks that (ab)use `--decrypt` work with 
`--output -` the same way.


> Item 2:  GnuPG Accepts Path Separators and Path Traversals in Literal 
Data "Filename" Field

>
> While this is a potentially serious bug, as it enables an attacker to 
potentially overwrite any file if the attacker can guess the file name, 
it also relies more on a social-engineering attack.  While a naive user 
might use the suggested command, a more-experienced user should 
immediately smell a rat.


Yes. This probably wouldn't fool a hardcore cypherpunk, but to be 
honest, it'd get me. Reaper compared this to a clickjacking attack in 
web exploitation, and we completely agree with this classification: this 
is an exploit chain that abuses the naivety of the user to trigger a 
*technical* issue.  Nevertheless, I believe that software should always 
do its best to protect against human error.


> The PoC uses ANSI escapes to cover up (erase, move left) the hash 
mark that makes the fake message viable as a shell script, the actual 
payload command (set as invisible text), and the prompt from GPG about 
writing the output file (which appears to be sent to the window title).  
I am uncertain how the user is suppos

Re: [oss-security] Many vulnerabilities in GnuPG

[Neal Gompa]

On Sun, Dec 28, 2025 at 9:51 PM Demi Marie Obenour
 wrote:
>
> On 12/28/25 05:00, Sam James wrote:
> > Demi Marie Obenour  writes:
> >
> >> 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.
> >
> > In 2.5.14:
>
> Fedora isn't running 2.5.14 even in Rawhide.  It's a zero-day for
> Fedora users at least.
>
> Upstream GnuPG is increasingly unwilling to collaborate with other
> OpenPGP implementations, and distros are having to patch GnuPG just to
> restore interoperability.  If possible, it would be best for distros
> to either outright fork the project and create a new upstream, or stop
> packaging GnuPG entirely in favor of Sequoia's compatibility layer.

The Fedora Linux family of distributions already doesn't use GnuPG in
the critical path anymore. RPM and DNF have been switched to
SequoiaPGP for quite some time. That change was inherited by Red Hat
Enterprise Linux 10 as well.

This is why we have PQC support in our PGP stuff.



-- 
真実はいつも一つ！/ Always, there's only one truth!

Re: [oss-security] Many vulnerabilities in GnuPG

[Werner Koch]

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


openpgp-digital-signature.asc
Description: PGP signature

Re: [oss-security] Many vulnerabilities in GnuPG

[Stephan Verbücheln]

GnuPG follows a traditional versioning scheme where even numbers (e.g.
2.2 and 2.4) are release branches and odd numbers (2.3 and 2.5) are
developer branches. So what we have to wait for is 2.4.9 fixing the
vulnerabilities.

Alternatively, distributions will fix the critical ones independently.
For instance, Debian 13 Trixie is using 2.4.7 and applies patches
downstream.

Regards


signature.asc
Description: This is a digitally signed message part

Re: [oss-security] Many vulnerabilities in GnuPG

[Salvatore Bonaccorso]

Hi,

FTR, these two got CVE assignments so far:

On Sun, Dec 28, 2025 at 12:47:30AM -0600, Jacob Bachmeyer wrote:
[...]
> Item 3: Cleartext Signature Plaintext Truncated for Hash Calculation
https://gpg.fail/formfeed

https://www.cve.org/CVERecord?id=CVE-2025-68972

> Item 5: Memory Corruption in ASCII-Armor Parsing
https://gpg.fail/memcpy

https://www.cve.org/CVERecord?id=CVE-2025-68973

Regards,
Salvatore

Re: [oss-security] Many vulnerabilities in GnuPG

[Demi Marie Obenour]

On 12/28/25 05:00, Sam James wrote:
> Demi Marie Obenour  writes:
> 
>> 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.
> 
> In 2.5.14:

Fedora isn't running 2.5.14 even in Rawhide.  It's a zero-day for
Fedora users at least.

Upstream GnuPG is increasingly unwilling to collaborate with other
OpenPGP implementations, and distros are having to patch GnuPG just to
restore interoperability.  If possible, it would be best for distros
to either outright fork the project and create a new upstream, or stop
packaging GnuPG entirely in favor of Sequoia's compatibility layer.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [oss-security] Many vulnerabilities in GnuPG

[Jeffrey Walton]

On Sun, Dec 28, 2025 at 6:14 PM Sam James  wrote:
>
> [...]
> Finally, to end the dump of what I know so far: Werner Koch has
> published a response to the cleartext signature vulnerabilities:
> https://gnupg.org/blog/20251226-cleartext-signatures.html.

Also see dkg's post from 2014 at
.  From the
article:

People often suggest that inline PGP signatures in e-mail are somehow
more compatible or more acceptable than using PGP/MIME. This is a
mistake. Inline PGP signatures are prone to several failure modes, up
to and including undetectable message tampering.

Jeff

Re: [oss-security] Many vulnerabilities in GnuPG

[Sam James]

Solar Designer  writes:

> 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),

Indeed. I'll note that several of the vulnerability pages (say
https://gpg.fail/sha1) have:

> Upcoming Timeline:
> [...]
> 21.12.2025: Disclosure of this report on https://seclists.org/fulldisclosure/

But I've not been able to find such a report there either.


signature.asc
Description: PGP signature

Re: [oss-security] Many vulnerabilities in GnuPG

[Sam James]

Demi Marie Obenour  writes:

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

In 2.5.14:

commit 115d138ba599328005c5321c0ef9f00355838ca9
Author: Werner Koch 
AuthorDate: Thu Oct 23 11:36:04 2025 +0200
Commit: Werner Koch 
CommitDate: Thu Oct 23 11:37:59 2025 +0200

gpg: Fix possible memory corruption in the armor parser.

* g10/armor.c (armor_filter): Fix faulty double increment.

* common/iobuf.c (underflow_target): Assert that the filter
implementations behave well.
--

This fixes a bug in a code path which can only be reached with special
crafted input data and would then error out at an upper layer due to
corrupt input (every second byte in the buffer is unitialized
garbage).  No fuzzing has yet hit this case and we don't have a test
case for this code path.  However memory corruption can never be
tolerated as it always has the protential for remode code execution.

Reported-by: 8b79fe4dd0581c1cd000e1fbecba9f39e16a396a
Fixes-commit: c27c7416d5148865a513e007fb6f0a34993a6073
which fixed
Fixes-commit: 7d0efec7cf5ae110c99511abc32587ff0c45b14f

In 2.5.13:

commit 8abc320f2a75d6c7339323a3cff8a8489199f49f
Author: Werner Koch 
AuthorDate: Wed Oct 22 12:39:15 2025 +0200
Commit: Werner Koch 
CommitDate: Wed Oct 22 12:39:15 2025 +0200

gpg: Error out on unverified output for non-detached signatures.

* g10/mainproc.c (do_proc_packets): Never reset the any.data flag.
--

Fixes-commit: 3b1b6f9d98b38480ba2074158fa640b881cdb97e
Updates-commit: 69384568f66a48eff3968bb1714aa13925580e9f
Reported-by: 8b79fe4dd0581c1cd000e1fbecba9f39e16a396a


commit 8abc320f2a75d6c7339323a3cff8a8489199f49f
Author: Werner Koch 
AuthorDate: Wed Oct 22 12:39:15 2025 +0200
Commit: Werner Koch 
CommitDate: Wed Oct 22 12:39:15 2025 +0200

gpg: Error out on unverified output for non-detached signatures.

* g10/mainproc.c (do_proc_packets): Never reset the any.data flag.

commit db9705ef594d5a2baf0e95e13cf6170b621dfc51
Author: Werner Koch 
AuthorDate: Wed Oct 22 11:19:55 2025 +0200
Commit: Werner Koch 
CommitDate: Wed Oct 22 11:20:10 2025 +0200

gpg: Avoid potential downgrade to SHA1 in 3rd party key signatures.

But it isn't clear to me what...
* the mapping between all of the vulnerabilities listed on the website is vs 
GnuPG commits (unfortunately
  no CVE identifiers yet either);
* GnuPG bug tracker links map to commits or vulnerabilities;
* whether these fixes are complete for a specific vulnerability or not.

The relevant public bugs I'm aware of for GnuPG are:
* https://dev.gnupg.org/T7909
* https://dev.gnupg.org/T7900
* https://dev.gnupg.org/T7902
* https://dev.gnupg.org/T7903
but some linked therein are still marked private.

Finally, to end the dump of what I know so far: Werner Koch has
published a response to the cleartext signature vulnerabilities:
https://gnupg.org/blog/20251226-cleartext-signatures.html.

sam


signature.asc
Description: PGP signature

Re: [oss-security] Many vulnerabilities in GnuPG

[Stephan Verbücheln]

Most of them are about unreliably displaying what was actually signed
and vertified.

The RCE bug was actually fixed as they already state in their slides.

https://github.com/gpg/gnupg/commit/ad0c6c33c3d6fe7ff7cc8c2e73d02ead5788e5b3



The overall status is not good though. In total (in their slides):
- 1 fixed
- 1 mitigated
- 3 unreleased patches in Git
- 7 unpatched
- 2 wontfox status.

Regards


signature.asc
Description: This is a digitally signed message part

Re: [oss-security] Many vulnerabilities in GnuPG

[Jacob Bachmeyer]

On 12/27/25 22:27, Solar Designer wrote:

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.


These are definitely edge cases and I think that item 9 is actually old 
news.


Comments on a first reading:

Overall, I have one very major point of disagreement here:  the OpenPGP 
clearsign format is useful precisely because it enables the signed 
message to be easily viewed with other tools, thus complicating attacks 
and making large-scale attacks much more likely to be detected.  (It 
only takes one user who looks at a clearsigned digest list with less(1) 
and sees a bunch of control sequences to raise an alarm.)



Item 1: Multiple Plaintext Attack on Detached PGP Signatures in GnuPG

Exploitation requires a very odd use of signatures.  Bob knows that he 
has a detached signature, and ordinarily a detached signature is simply 
used to verify the signed file, after which the signed file is used 
directly.


This is also the first time I have seen --decrypt suggested for reading 
a signed message; does this also work if the message is encrypted?


Mallory can be assumed to have Bob's public key and could therefore 
generate a second encrypted message to Bob if Alice's message was signed 
and encrypted.  There would be an interesting indicator of compromise:  
an abnormally-large detached signature.


This exposes *another* bug in GPG:  documentation says that --decrypt 
will reject an unencrypted input, yet the PoC involves using it with 
exactly that.



Item 2:  GnuPG Accepts Path Separators and Path Traversals in Literal 
Data "Filename" Field


While this is a potentially serious bug, as it enables an attacker to 
potentially overwrite any file if the attacker can guess the file name, 
it also relies more on a social-engineering attack. While a naive user 
might use the suggested command, a more-experienced user should 
immediately smell a rat.


The PoC uses ANSI escapes to cover up (erase, move left) the hash mark 
that makes the fake message viable as a shell script, the actual payload 
command (set as invisible text), and the prompt from GPG about writing 
the output file (which appears to be sent to the window title). I am 
uncertain how the user is supposed to see the next prompt, as the 
invisible text mode does not appear to be reset.



Item 3: Cleartext Signature Plaintext Truncated for Hash Calculation

GPG uses in-band signaling if a line is too long. Comments in the GPG 
sources acknowledge that this is a hack.


The exploit does have a problem in that it reports an error about 
"invalid armor" due to a line being too long. Also, while it works if 
the message is fed directly to a terminal, I suspect that reading the 
message with less(1) would show interesting anomalies.


Item 4: Encrypted message malleability checks are incorrectly enforced 
causing plaintext recovery attacks


This item admits not actually having a complete attack, and I am unsure 
how exactly this l