Severe bug in Libgcrypt – used by GPG and others – is a whole heap of trouble, prompts patch scramble

Google Project Zero researcher Tavis Ormandy on Thursday reported a severe flaw in Libgcrypt 1.9.0, an update to the widely used cryptographic library that was released ten days ago.

Libgcrypt is a general-purpose crypto module developed for GNU Privacy Guard (GnuPG or GPG), a free software implementation of the OpenPGP standard (RFC4880). It provides assorted cryptographic primitives or building blocks that applications can implement to encrypt and decrypt data.

The code is present in Linux distributions like Fedora and Gentoo, and is used in macOS package manager Homebrew. It’s also the crypto library used by systemd for DNSSEC.

However, because Libgcrypt 1.9.0 was only recently released, it hasn’t been widely incorporated into other projects yet. It was included in Fedora 34 but that hasn’t been officially released and the library will presumably be replaced with a good version come launch day; Gentoo did adopt it but is in the process of getting rid of it. There’s a Homebrew patch too, which apparently required extra work to resolve issues with the 1.9.1 update that broke builds on Intel CPUs.

The identified bug is a heap buffer overflow and it’s considered rather serious because it’s easily exploitable.

“Just decrypting some data can overflow a heap buffer with attacker controlled data, no verification or signature is validated before the vulnerability occurs,” explains Werner Koch, principal developer of GnuPGP in the security advisory. “…Exploiting this bug is simple and thus immediate action for 1.9.0 users is required.”

Action in this case means either adopting 1.9.1 or reverting to an older version, LTS 1.8.5 or better.

Filippo Valsorda, a cryptography and software engineer on Google’s Go programming language team, dissected the bug in a Twitter thread and lays the blame in part on the lack of memory safety in Libgcrypt’s C code.

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.

— Filippo Valsorda ??❤️ ✊ (@FiloSottile) January 29, 2021

At the heart of the bug is a C structure in Libgcrypt that, highly simplified, looks like:

struct gcry_md_block_ctx
{ char buffer[128]; int stuff; function_ptr func;
}

You can overflow buffer with input data, as described above, to alter the function pointer func, which is called shortly after, to redirect control of the program to attacker-defined instructions. On little-endian machines, such as x86 and modern Arm, partially overwriting the function pointer – just the low bytes – will defeat ASLR. It’s trivial to exploit by getting someone to decrypt a maliciously crafted document, which then starts executing code on their computer to snoop on them, ransom their files, leak data, and so on.

Ormandy’s in-depth analysis of the programming blunder can be found here.

Valsorda points out that the vulnerability was introduced in an effort to mitigate timing side channel attacks, and is critical of the way the buffered data length is managed.

Hanno Böck, a German IT journalist and hacker, expressed similar criticism and noted that the maintainers of GnuPGP don’t appear to use an AddressSanitizer (or asan) in testing, which could have helped catch the bug. He also submitted a bug report pointing out that the gnupg.org webpage includes insecure git:// protocol links, a risk because they are vulnerable to MITM attacks.

Koch, who made an appeal for funding in 2015 after propping up open source encryption code without recompense, responded by telling Böck to stay in his lane. “Stick to your channels and get back after you have learned some basic developer workflows,” he replied, marking the submission as invalid.

Among the Twitterati following the bug discussion, developer Chris Cowan (@macil_tech) quipped, “You’d think encryption software maintainers would be more enthusiastic about using encryption.” ®

READ MORE HERE