[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c3b701f4-057b-41ca-9848-1e205e79fd48@gmail.com>
Date: Tue, 30 Dec 2025 06:29:36 -0500
From: Demi Marie Obenour <demiobenour@...il.com>
To: oss-security@...ts.openwall.com, "Lexi Groves (49016)"
<contact@....fail>, jcb62281@...il.com, Solar Designer <solar@...nwall.com>
Subject: Re: Many vulnerabilities in GnuPG
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) <alice@....org>"
> > > ```
>
> 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 <demo@....fail>" [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)
Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
