Google discloses a severe flaw in widely used Libgcrypt encryption library
Google discovered a flaw in GNU Privacy Guard (GnuPG)’s Libgcrypt encryption library that could be exploited to get remote code execution.
The popular white hat hacker Tavis Ormandy of Google Project Zero discovered a severe heap buffer overflow flaw in GNU Privacy Guard (GnuPG)’s Libgcrypt encryption software could have allowed a remote attacker to write arbitrary data to the target machine, potentially leading to code execution.
“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.” reads the advisory published by Ormandy. “This code in _gcry_md_block_write (part of the generic block buffer abstraction code) assumes that the occupied space in a block buffer cannot exceed the blocksize of the algorithm:”
Libgcrypt is a general purpose cryptographic library originally based on code from GnuPG. It provides functions for all cryptographic building blocks and is present in major Linux distributions like Fedora and Gentoo, along with macOS package manager Homebrew. It’s also the crypto library used by systemd for DNSSEC.
The vulnerability was discovered on January 28 and only impacts version 1.9.0 of libgcrypt, the GnuPG team addressed it in less than 24 hours with the release of a new version. The team recommends users to stop using the vulnerable version of the library.
“A severe bug was reported yesterday evening against Libgcrypt 1.9.0 which we released last week. A new version to fix this as weel as a couple of build problems will be released today.” states the advisory published by the GnuPG team. “In the meantime please stop using 1.9.0. It seems that Fedora 34 and Gentoo are already using 1.9.0”
The cryptography engineer Filippo Valsorda analyzed the bug in a Twitter thread and reported that the root cause of the issue is the lack of memory safety in Libgcrypt’s C code.
Right, so there are function pointers and stuff, but this is in sha256_final.
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.
No idea why it sets count. pic.twitter.com/GYJOddEPxl
— Filippo Valsorda
(@FiloSottile) January 29, 2021
(@FiloSottile) January 29, 2021But then! md_write might still be called in a very mild attempt at mitigating timing side channels.
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. pic.twitter.com/LYC9PsURqn
— Filippo Valsorda
Valsorda explained that the vulnerability was introduced by the development team to mitigate timing side-channel attacks.
The vulnerability could be exploited by an attacker by sending the library a specially-crafted block of data to decrypt that could trigger the buffer overflow.
“We have to announce the availability of Libgcrypt version 1.9.1. This version fixes a critical security bug in the recently released version 1.9.0. If you are already using 1.9.0 please update immediately to 1.9.1.” wrote Libgcrypt author Werner Koch.
“Exploiting this bug is simple and thus immediate action for 1.9.0 users is required. A CVE-id has not yet been assigned. We track this bug at https://dev.gnupg.org/T5275.“
If you want to receive the weekly Security Affairs Newsletter for free subscribe here.
|
|
Pierluigi Paganini
(SecurityAffairs – hacking, Libgcrypt)
The post Google discloses a severe flaw in widely used Libgcrypt encryption library appeared first on Security Affairs.
If you like the site, please consider joining the telegram channel or supporting us on Patreon using the button below.
