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) <[email protected]>" > > > ``` > > 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 <[email protected]>" [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
