LWN: Comments on "Critical security problem in Libgcrypt 1.9.0"

Critical security problem in Libgcrypt 1.9.0

nix — Thu, 04 Feb 2021 01:12:05 +0000

I don't find the Beale story very convincing. Three ciphertexts, one of which uses a trivial (and incompetently executed) book cipher with the US Declaration of Independence as key, and the other two are "unknown". Could that be because they use a remarkable never subsequently identified cipher? Sure it could. But a far more likely explanation is that they're effectively gibberish, and the Beale ciphers are a prank that outlasted its expected value.

Given that the first cipher, when decrypted using the same modified-Declaration-of-Independence key as the (pre-decrypted) B2, has fairly long near-alphabetic runs in it which are very unlikely to occur by chance, I would have to agree with Gillogly: this is a not especially good hoax, and B1 and B3 have no decryption (or, rather, B1 has long been decrypted: its decryption is the near-gibberish shown by Gillogly, alphabetic runs and all).

Critical security problem in Libgcrypt 1.9.0

mathstuf — Wed, 03 Feb 2021 17:59:28 +0000

IIRC, the LGPL still requests replaceability of the LGPL code in the end (e.g., I can take your usage of the LGPL code, recompile my modifications myself, then inject them into the end product). Now, one can do this because the crates *are* generally all FOSS and executable crates usually (well, certainly should) commit their `Cargo.lock` file into the repository. Using this information, I can get a binary with my modifications, but it isn't as trivial as "replace this .so and restart the program". I suspect this is sufficient, but any non-FOSS binary is going to have trouble consuming LGPL (or stronger) licensed code that ends up statically linked (as Rust basically always does as of today).

Critical security problem in Libgcrypt 1.9.0

ballombe — Wed, 03 Feb 2021 14:29:48 +0000

> This means the list of possible use cases for your library is now reduced to GPL open source projects.

Thanks for your clarification, but how is this different from any other language ?
If you write a GPL library in any language, in general it can only be used in GPL software

What about the LGPL ?

Critical security problem in Libgcrypt 1.9.0

Jonno — Wed, 03 Feb 2021 11:18:29 +0000

> [...] do you *distribute* a ready-built app, including all the crates, or does the user assemble the app on their system downloading the crates separately from master app?

Both. Developers usually download and build each crate separately (usually by running e.g. "cargo install ripgrep"). End users usually download pre-built binaries (usually by running e.g. "apt install ripgrep"), which usually (but not always) has statically linked in most dependent crates.

Critical security problem in Libgcrypt 1.9.0

Wol — Wed, 03 Feb 2021 09:42:09 +0000

Not knowing Rust, but do you *distribute* a ready-built app, including all the crates, or does the user assemble the app on their system downloading the crates separately from master app?

Because if it's the latter, the GPL has no teeth ...

Cheers,
Wol

Critical security problem in Libgcrypt 1.9.0

rvolgers — Wed, 03 Feb 2021 02:40:33 +0000

There's plenty we can disagree on, but let me at least make clear what I was saying.

By "Rust ecosystem" I didn't mean "everybody who writes Rust", I mean the library ("crates") ecosystem, which represents functionality you can use in your own library or app by adding a single line to your project configuration. This is a major strength of Rust.

Just about all major crates I can think of are permissively licensed, many of them under the same license as Rust itself (dual licensed Apache 2 and MIT, which is about as permissive as it gets). Because of this they can mix and match freely, using lots of types and abstractions defined in external crates without imposing significant license obligations.

Now let's say I want to write a crate for package management which can verify PGP signatures, or a crate for mail processing which optionally supports encrypted mails, or a certificate manager which also supports PGP keys. If I use the Sequoia crates then any app built using my crate will include GPL code, meaning the maker of the app must provide the source code for the app (including all other referenced crates) under the GPL as well.

This means the list of possible use cases for your library is now reduced to GPL open source projects. That's fine if that's what you want, but it's very different from the normal / expected arrangement you get when you reference a crate.

Critical security problem in Libgcrypt 1.9.0

Lionel_Debroux — Mon, 01 Feb 2021 20:48:29 +0000

Thanks :)
Now, I remember seeing a mention of cryptofuzz, but anyway, I didn't know libgcrypt was fuzzed through it.
Nearly 100 issues mentioned by cryptofuzz's README represent a pretty nice roster.

Critical security problem in Libgcrypt 1.9.0

tialaramex — Mon, 01 Feb 2021 20:08:16 +0000

> Step 2. Use a private cipher.

It is _extremely_ likely that if somebody actually does want to decrypt your messages this means they succeed. Of course if they didn't want to decrypt your messages then absolutely anything would be fine.

It's much harder to create a secure cipher than to break something people mistakenly believed was unbreakable. Hand rolled systems are also more likely to induce operational errors that ruin your security (e.g. people sending two versions of the same message encrypted with the same key but slightly different content, GnuPG would make this extremely difficult to do, but hand rolled systems cause this all the time)

I don't find the Beale story very convincing. Three ciphertexts, one of which uses a trivial (and incompetently executed) book cipher with the US Declaration of Independence as key, and the other two are "unknown". Could that be because they use a remarkable never subsequently identified cipher? Sure it could. But a far more likely explanation is that they're effectively gibberish, and the Beale ciphers are a prank that outlasted its expected value.

Critical security problem in Libgcrypt 1.9.0

jukivili — Mon, 01 Feb 2021 18:29:53 +0000

libgcrypt, as well as many other crypto libraries, are being fuzzed in OSS-fuzz through cryptofuzz project, https://github.com/guidovranken/cryptofuzz

Critical security problem in Libgcrypt 1.9.0

ballombe — Mon, 01 Feb 2021 18:19:58 +0000

It is difficult not to read the post I replied to as implying that the GPL cannot be used within the rust ecosytem, which seems strange.

Critical security problem in Libgcrypt 1.9.0

dd9jn — Mon, 01 Feb 2021 16:34:08 +0000

There are folks who proxy fuzzing reports. The Google fuzzing thingy is not directly usable for any self-respecting privacy hacker because it requires a Google account just for viewing the reports.

Critical security problem in Libgcrypt 1.9.0

dd9jn — Mon, 01 Feb 2021 16:30:13 +0000

Most of the NEWS items are about bug fixes for 1.9.0. These build problems are actually expected to happen after ~3 years of development with only few people interested in testing the Git version.

The performance improvements for z390 were finished only after the 1.9.0 release so I merged them into 1.9.1 because branching at this time does not yet make sense.

From experience we know that a Beta or RC release does not yield any better result than our public Git. So, unfortunately, the first releases of a new branch are somewhat rough. And no, we can't test all kind of system configurations people are using. After all it is free software and everyone can fix little bugs. There are hints and patches on the problems in the release bug (https://dev.gnupg.org/T4294).

A new release was anyway planned for Friday; the security bug reported by Tavis merely moved the release to Friday morning. And yes, the broken --disable-asm was an oversight but that is also a special configuration which we don't need on our major platforms: Linux on amd64, Windows32 and Windows 64.

Critical security problem in Libgcrypt 1.9.0

laarmen — Mon, 01 Feb 2021 13:18:49 +0000

I interpreted more as a statement of fact. You can find statistics at this address :

https://gist.github.com/passcod/2e1983ce415b32bdf3a0

with an 2020 result in the comments. While GPL 3 is in the top 5 licenses, it isn't nearly as used as the MIT license (which I presume is the same as the Expat license). As a lurker in the Rust community, I've never felt like there was any more FUD directed towards the GPL in that community than in any other.

Critical security problem in Libgcrypt 1.9.0

ballombe — Mon, 01 Feb 2021 10:10:01 +0000

Are you implying that the rust ecosystem is somehow scaring people away from the GPL ?

Critical security problem in Libgcrypt 1.9.0

epa — Sun, 31 Jan 2021 19:27:24 +0000

Right, it did seem a bit weird to see such a long list of new features in a security advisory, but I assumed there must be some good reason for it...

Speed of interpreter vs compiler

epa — Sun, 31 Jan 2021 19:25:11 +0000

I was thinking in particular of the executable semantics described in http://fsl.cs.illinois.edu/pubs/ellison-rosu-2012-popl.pdf which runs at best 200 times slower than native code and at worst millions of times slower. Of course there is plenty of scope for optimization. Valgrind catches memory errors but it doesn’t nail down absolutely every case of undefined behaviour in C. Then again, that standard of rigour is not needed to eliminate a large number of security bugs in practice.

There is a spectrum from fully specified, interpreted machines like the one above (completely safe but very slow) to small modifications of native code like stack canaries and randomized function locations (minimal speed impact in most cases, but only some exploits are stopped). For the sake of my argument I wanted to say that even at a conservative estimate of interpreted code being thousands of times slower, it’s still a worthwhile tradeoff given abundant hardware but scarce programmer time to rewrite everything.

Critical security problem in Libgcrypt 1.9.0

eharris — Sun, 31 Jan 2021 19:19:36 +0000

@tialaramex
Quote: "If you did want secure email ... almost immediately you'll realise that you can't encrypt the metadata that makes email actually work..."
*
There's "secure".....and then there's "private". You can have both with much less trouble. Step 1: use throwaway email addresses. Step 2. Use a private cipher.
*
Although both steps requires a community to do some organising, and step 2 requires some effort, the results are also very likely to be immune to "backdoors". For a century old example take a look at this: https://en.wikipedia.org/wiki/Beale_ciphers

Speed of interpreter vs compiler

jreiser — Sun, 31 Jan 2021 18:29:37 +0000

Interpreted code is thousands of times slower

Nonsense. The rule-of-thumb speed ratio between compiled and interpreted code is only 10:1. Valgrind has a typical slowdown of only 20x to 40x in contrast to its compiled input.

Critical security problem in Libgcrypt 1.9.0

epa — Sun, 31 Jan 2021 09:58:03 +0000

I believe most of the exploits would be blocked by running the existing C code with stricter run-time checking, for example in one of the C interpreters that exist. In these environments any kind of memory trampling immediately terminates the program. Interpreted code is thousands of times slower, of course, but that can be a fair trade-off (with speed critical parts still compiled, and code review can concentrate on those parts).

Rust or another safe language is great, of course, but it is very expensive in programmer time to rewrite things in a new language. Just as obsolete hardware lives on in emulation, we can create a slower and safer environment for legacy C code in places where a single memory handling bug can become a security hole.

Critical security problem in Libgcrypt 1.9.0

rvolgers — Sun, 31 Jan 2021 02:44:05 +0000

There is sequoia-pgp, which is extremely impressive and aims to be a production quality implementation: https://sequoia-pgp.org/

However, because sequoia-pgp uses the GPL, which is rather uncommon in the Rust ecosystem, it is mostly useful for other GPL apps and for its command line tools (which, I'm not sure whether those are release quality yet).

For use within the Rust ecosystem there is rPGP (https://github.com/rpgp/rpgp), which is missing some functionality and lacks quite a lot of polish.

Critical security problem in Libgcrypt 1.9.0

tialaramex — Sat, 30 Jan 2021 15:08:02 +0000

If the thing you want to do is encrypt stuff, there is a Rust implementation of age, rage

https://github.com/str4d/rage

If the thing you want to do is sign things, there is a Rust implementation of signify, signify-rs

https://github.com/badboy/signify-rs

A *lot* of applications that rely on GnuPG today would ideally use age or signify (thus rage or signify-rs) instead and could be migrated.

These tools intentionally don't try to shoe horn an alternative to S/MIME into their feature set, so if your interest in GnuPG is as an alternative to S/MIME then they don't have you covered, but you're probably in a world of pain for choosing that even if there are no "buffer overflows, double frees, and out-of-bounds writes".

If you did want secure email, trying to build it yourself from age and signify would at least open your eyes to all the horrible problems and painful compromises on your path. For example, almost immediately you'll realise that you can't encrypt the metadata that makes email actually work, and that if you try to sign it, intermediary transports will change that metadata and invalidate the signature. Does OpenPGP offer a fiendishly clever yet reliable workaround you'd never have imagined? Er, no.

Critical security problem in Libgcrypt 1.9.0

Lionel_Debroux — Sat, 30 Jan 2021 09:50:08 +0000

I don't know how well libgcrypt lends itself to fuzzing, but at least, I can't currently see an occurrence of "gcrypt" at https://github.com/google/oss-fuzz/tree/master/projects , and libgcrypt would probably qualify for "To be accepted to OSS-Fuzz, an open-source project must have a significant user base and/or be critical to the global IT infrastructure."

Critical security problem in Libgcrypt 1.9.0

mjg59 — Sat, 30 Jan 2021 09:08:42 +0000

Impact in this case is fortunately low due to the small period of time between the code being released and the bug being found, but the fact that it's something that could probably have been picked up with a better test suite and CI that builds with ASAN in the months between the commit landing and the issue being identified is still something to be worried about. Dev practices from the 90s just aren't acceptable any more. Security critical code really needs to be doing more.

Critical security problem in Libgcrypt 1.9.0

karkhaz — Sat, 30 Jan 2021 07:48:25 +0000

> There is yet no released GnuPG version hich requires Libgcrypt 1.9

> If you are using the 1.8 LTS branch you are not affected. While you are checking anyway please make sure that you have at least 1.8.5.

However, gnupg on Arch Linux did use libgcrypt 1.9.0. The current Arch Linux libgcrypt package since yesterday is 1.9.1-1, so (strong Greg Kroah-Hartman voice) all users are strongly advised to upgrade. Looking at the history of the libgcrypt PKGBUILD, Arch has been using libgcrypt 1.9.0 since 19 January, and 1.8.7 from 25 October till then.

Critical security problem in Libgcrypt 1.9.0

flussence — Fri, 29 Jan 2021 20:14:23 +0000

Ignoring the ongoing mud-slinging at security researchers the project owner is doing in the background today, it turns out 1.9.1's build is broken in certain configurations because they conflate security and feature updates: https://dev.gnupg.org/T5277

Critical security problem in Libgcrypt 1.9.0

andy_shev — Fri, 29 Jan 2021 19:27:54 +0000

Go ahead, do it!

Critical security problem in Libgcrypt 1.9.0

tchernobog — Fri, 29 Jan 2021 17:00:14 +0000

Considering the amount of recent CVEs (well, recent and old) about buffer overflows, double frees, and out-of-bounds writes, I wonder if some security-critical utilities shouldn't rather be written in a language which makes it harder to do these mistakes, such as Rust.