[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SYCPR01MB366178C350BB2649FA5B82D6EEBCA@SYCPR01MB3661.ausprd01.prod.outlook.com>
Date: Tue, 30 Dec 2025 00:57:31 +0000
From: Peter Gutmann <pgut001@...auckland.ac.nz>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: Re: Many vulnerabilities in GnuPG
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.
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.
