[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8k5f0aRjGjP4ADDWG3iocN_mgu08P2n7KTQ+W-5Oc4Atg@mail.gmail.com>
Date: Wed, 31 Dec 2025 01:59:12 -0500
From: Jeffrey Walton <noloader@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Many vulnerabilities in GnuPG
On Tue, Dec 30, 2025 at 11:54 PM Demi Marie Obenour
<demiobenour@...il.com> 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) <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?
For completeness, the scheme Debian and APT use is documented in the
Debian manual. See Section 7.5.1 at
<https://www.debian.org/doc/manuals/securing-debian-manual/deb-pack-sign.en.html>.
Jeff
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.
