Bad Security Bug in GnuPG: C Language Blamed (Yet Again)
GnuPG has a serious vulnerability, in a library also used elsewhere. Libgcrypt 1.9.0 contains a classic programming error, discovered by one of the usual suspects.
Digging deeper, the code seems badly structured, with plenty of scope for other bugs to lie beneath the surface. Which is a worry, because these encryption primitives are used in other code—which many of us rely on daily, such as DNSSEC.
Is it the fault of the programming language, C? Or is it just bad design? In today’s SB Blogwatch, we fight the good fight.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Graybeard stokes dusty fire.
Rabbits, White Rabbits
What’s the craic? Zeljka Zorz inserts tab ‘A’ into slot ‘B’—“Serious vulnerability found in Libgcrypt, GnuPG’s cryptographic library”:
Libgcrypt 1.9.0, the newest version of a cryptographic library integrated in the GNU Privacy Guard (GnuPG) free encryption software, has a “severe” security vulnerability and should not be used, warned Werner Koch … the principal developer behind GnuPG and the author of Libgcrypt. … 1.9.0 was released on January 19 and was meant to be integrated in the upcoming GnuPG 2.3.
…
It’s a heap buffer overflow due to an incorrect assumption in the block buffer management code. Just decrypting some data can overflow a heap buffer with attacker controlled data.
…
Fedora 34 (scheduled to be released in April 2021) and Gentoo Linux are already using the vulnerable version. … Version 1.9.1, which fixes the flaw, is available for download.
Should I be worried? Dennis Fisher deciphers the story—“Severe Bug … Fixed”:
The vulnerability only affects the one version. … The developers of Libgcrypt have removed the vulnerable version from the download servers and released a new version that has a fix.
…
However, the bug is very easy to exploit and the result of triggering it is that an attacker would be able to write arbitrary data to the target machine. Researcher Tavis Ormandy of Google Project Zero discovered the flaw and reported it to the Libgcrypt developers, who pushed out a patch within a day.
…
The vulnerability was first introduced about two years ago during the development of version 1.9 of Libgcrypt but was only identified this week. … Libgcrypt is a general cryptographic library that provides the building blocks for performing cryptographic functions.
…
It’s used in a variety of applications, with GnuPG being the most well-known. … Any developers that have Libgcrypt 1.9.0 in their apps should update as soon as possible.
Ahhh, it’s Tavis again. Mister Ormandy counts in his massive brain—“Issue 2145”:
There is a heap buffer overflow in libgcrypt due to an incorrect assumption in the block buffer management code. Just decrypting some data can overflow a heap buffer with attacker controlled data, no verification or signature is validated before the vulnerability occurs.
…
_gcry_md_block_write … assumes that the occupied space in a block buffer cannot exceed the blocksize. … This is then passed to buf_cpy(), essentially a memcpy. … I believe this is easily exploitable, the overflowed buffer is immediately adjacent to a function pointer that is immediately called after the overflow.
…
The GnuPG team responded quickly, they sent a warning to stop using the vulnerable version as soon as they received my report. … And a new version was released a few hours later.
How could this have happened? GPG project lead Werner Koch explains—“Security fix”:
Exploiting this bug is simple and thus immediate action for 1.9.0 users is required. … Please update immediately to version 1.9.1.
…
Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and still mostly financed by donations. Three full-time employed developers as well as two contractors exclusively work on GnuPG and closely related software like Libgcrypt.
…
Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG and Libgcrypt in a good and secure shape. … Thanks to Tavis Ormandy for finding and reporting the bug. We are sorry for the trouble.
Good old open source, eh? Filippo Valsorda—@FiloSottile—demonstrates the maxim about all bugs being shallow:
If there’s no space in the block for the length suffix, it uses space from the 128 byte buf to fit another one. Then it leaves count, the buffered data length, at 120.
…
blocksize is 64, (blocksize – hd->count) underflows, the if doesn’t hit so buf_cpy copies the whole input to buf. If it’s more than 8 bytes: heap overflow.
…
What went wrong? Of course, in primis, it’s C and memory unsafety. Arithmetic errors happen. In C they instantly become exploitable vulnerabilities. In a hash function! There’s also a lot of reliance on distant state invariants, which is unsafe even by C standards.
…
A defensive strategy here would be to use a copy function that is aware of the constant size of buf. Instead the patch just adjusts the invariance ad-hoc. … I am physically uncomfortable with how state is handled in there.
Ahh yes, blame the C language. “A bad workman blames his tools,” as the old, un-PC saying goes. DrXym obliges:
And the modest mechanic takes whatever help they can get from a language and would prefer one that doesn’t lay a minefield of bull**** bugs that are exploitable, cause crashes or otherwise delay or degrade the quality or security of the final product. Libgcrypt must be one of the most reviewed open source projects out there and if that can suffer an exploit I guarantee you that other software which doesn’t receive the same level of scrutiny has plenty more.
…
Software that has been practically forensically audited and yet serious bugs are found from time to time [is] often the result of language constructs. If it happens there with hundreds of eyeballs on the code then absolutely guaranteed it happens everywhere else and with greater frequency.
C considered harmful? After looking at the code, AleRunner has a more nuanced POV:
Surely some of the long scary functions manipulating buffers … need to be carefully refactored into shorter simpler (possibly inlined) functions with lots of careful aggressive test cases. Not that I’m volunteering to do it at this point, so I’m not going to criticise those working on it, but, looking at the code we really need lots of people to learn how this stuff works and improve it.
Sure, that’s what’s included by default in C. But it is possible to write it in ways that make it to be safer even without changing language.
That’s what they said. sed gawk agrees: [You’re fired—Ed.]
This incorrect assertion is rolled out every so often. The “class of errors” is “didn’t run a static and dynamic analysis tools”. The language level issue is that the C code is a little messy and should be tested with asan/ubsan.
The code level issue is ad-hoc buffer management, rather than a restartable block function. … Because the buffer management is ad-hoc, an invariant got missed.
And nagora suggests two other suggestions:
Do fuzzing as well. And review the code by eye every so often; you’ll have learned stuff since you wrote it.
Meanwhile, this Anonymous Coward fingers the real problem:
This is just another instance of … lone or understaffed volunteers maintaining legacy code that over time became more and more of a rats nest [and] that the current devs have been propping up while their pleas for help fall on deaf ears. A lesson not learned apparently.
…
The open source community should try to tackle the underlying issues head on. … Support the projects that form the primary attack surface of open source software, build up the team and infrastructure to start auditing some of this stuff, and … some of these projects should be re-implemented in a more modern development environment.
…
This code base looks like it’s overdue for a deep cleaning, but even then, the next commit could easily introduce a new set of vulnerabilities. Even good programmers make bad bugs, and they are often harder to find.
And Finally:
You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or [email protected]. Ask your doctor before reading. Your mileage may vary. E&OE. 30.
Image sauce: Nikhil Mitra (via Unsplash)
