[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d46c3c34-0fa8-4b79-a624-b7ccc9662ce8@gmail.com>
Date: Tue, 30 Dec 2025 04:04:18 -0500
From: Demi Marie Obenour <demiobenour@...il.com>
To: oss-security@...ts.openwall.com, Peter Gutmann <pgut001@...auckland.ac.nz>
Subject: Re: Many vulnerabilities in GnuPG
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
<https://github.com/QubesOS/qubes-rpm-oxide>. 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 "pgpencrypt file", and
> there's little facility to perform attacks like in the talk because there's no
> extra capabilities there to attack.
Are these available anywhere?
(snip)
> [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.
Yeah, that's *embarrassing*.
--
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.
