Severe bug in Libgcrypt – used by GPG and others – is a whole heap of trouble, prompts patch scramble
(2021/01/29)
- Reference: 1611951706
- News link: https://www.theregister.co.uk/2021/01/29/severe_libgcrypt_bug/
- Source link:
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 [1]released ten days ago .
Libgcrypt is a general-purpose crypto module developed for [2]GNU Privacy Guard (GnuPG or GPG), a free software implementation of the OpenPGP standard ( [3]RFC4880 ). It provides assorted cryptographic primitives or building blocks that applications can implement to encrypt and decrypt data.
[4]
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 [5]used by systemd for DNSSEC.
Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [6]READ MORE
[7]
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 [8]in the process of getting rid of it . There's [9]a Homebrew patch too, which apparently required extra work to resolve issues with the 1.9.1 update that [10]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 [11]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) [12]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 [13]here .
Valsorda [14]points out that the vulnerability was introduced in an effort to mitigate timing side channel attacks, and [15]is critical of the way the buffered data length is managed.
Hanno Böck, a German IT journalist and hacker, [16]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 [17]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 [18]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.
[19]
Among the Twitterati following the bug discussion, developer Chris Cowan (@macil_tech) [20]quipped , "You'd think encryption software maintainers would be more enthusiastic about using encryption." ®
Get our [21]Tech Resources
[1] https://lists.gnupg.org/pipermail/gnupg-announce/2021q1/000453.html
[2] https://gnupg.org/index.html
[3] https://www.ietf.org/rfc/rfc4880.txt
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YBSThbQLB1m-8HuAP0aWrwAAABU&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://github.com/systemd/systemd/search?q=libgcrypt%20DNSSEC
[6] https://www.theregister.com/2019/07/18/microsoft_rust_security/
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YBSThbQLB1m-8HuAP0aWrwAAABU&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c242f6750f7ccb8546366ff8b8f080cefcdc6f38
[9] https://github.com/Homebrew/homebrew-core/pull/69980
[10] https://twitter.com/FiloSottile/status/1355153432081031171?s=20
[11] https://lists.gnupg.org/pipermail/gnupg-announce/2021q1/000456.html
[12] https://twitter.com/FiloSottile/status/1355133524064481282?ref_src=twsrc%5Etfw
[13] https://bugs.chromium.org/p/project-zero/issues/detail?id=2145
[14] https://twitter.com/FiloSottile/status/1355136172280975363?s=20
[15] https://twitter.com/FiloSottile/status/1355134373415280644?s=20
[16] https://twitter.com/hanno/status/1355133575016951811?s=20
[17] https://dev.gnupg.org/T5280
[18] https://www.theregister.com/2015/02/05/gnupg_funding/
[19] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YBSThbQLB1m-8HuAP0aWrwAAABU&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[20] https://twitter.com/macil_tech/status/1355205210893905920?s=20
[21] https://whitepapers.theregister.com/
Libgcrypt is a general-purpose crypto module developed for [2]GNU Privacy Guard (GnuPG or GPG), a free software implementation of the OpenPGP standard ( [3]RFC4880 ). It provides assorted cryptographic primitives or building blocks that applications can implement to encrypt and decrypt data.
[4]
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 [5]used by systemd for DNSSEC.
Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again [6]READ MORE
[7]
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 [8]in the process of getting rid of it . There's [9]a Homebrew patch too, which apparently required extra work to resolve issues with the 1.9.1 update that [10]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 [11]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) [12]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 [13]here .
Valsorda [14]points out that the vulnerability was introduced in an effort to mitigate timing side channel attacks, and [15]is critical of the way the buffered data length is managed.
Hanno Böck, a German IT journalist and hacker, [16]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 [17]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 [18]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.
[19]
Among the Twitterati following the bug discussion, developer Chris Cowan (@macil_tech) [20]quipped , "You'd think encryption software maintainers would be more enthusiastic about using encryption." ®
Get our [21]Tech Resources
[1] https://lists.gnupg.org/pipermail/gnupg-announce/2021q1/000453.html
[2] https://gnupg.org/index.html
[3] https://www.ietf.org/rfc/rfc4880.txt
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YBSThbQLB1m-8HuAP0aWrwAAABU&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://github.com/systemd/systemd/search?q=libgcrypt%20DNSSEC
[6] https://www.theregister.com/2019/07/18/microsoft_rust_security/
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YBSThbQLB1m-8HuAP0aWrwAAABU&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c242f6750f7ccb8546366ff8b8f080cefcdc6f38
[9] https://github.com/Homebrew/homebrew-core/pull/69980
[10] https://twitter.com/FiloSottile/status/1355153432081031171?s=20
[11] https://lists.gnupg.org/pipermail/gnupg-announce/2021q1/000456.html
[12] https://twitter.com/FiloSottile/status/1355133524064481282?ref_src=twsrc%5Etfw
[13] https://bugs.chromium.org/p/project-zero/issues/detail?id=2145
[14] https://twitter.com/FiloSottile/status/1355136172280975363?s=20
[15] https://twitter.com/FiloSottile/status/1355134373415280644?s=20
[16] https://twitter.com/hanno/status/1355133575016951811?s=20
[17] https://dev.gnupg.org/T5280
[18] https://www.theregister.com/2015/02/05/gnupg_funding/
[19] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YBSThbQLB1m-8HuAP0aWrwAAABU&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[20] https://twitter.com/macil_tech/status/1355205210893905920?s=20
[21] https://whitepapers.theregister.com/
45RPM
The problem isn’t C - the problem is developers misusing it. Would you ban formula 1 because the average motorist can’t handle a racing car? No. You have to use the tool appropriately, and make sure that the programmer has the skills to use it.
I’d argue that that struct should contain the buffer size as well and only access for read or write via a function which checks the size before accessing the buffer. When calloc’ing (or malloc’ing) or freeing the buffer size gets updated by the function making the updates.
systemd and DNSSEC ?
Nate Amsden
wtf? I wouldn't be surprised if systemd is doing DNS these days but isn't DNSSEC a server-to-server thing not a client to server thing? If so wtf is systemd doing with it?
on the topic of DNSSEC I came across this blog a while back and found it informative, rips into DNSSEC https://sockpuppet.org/blog/2015/01/15/against-dnssec/
"In fact, it does nothing for any of the “last mile” of DNS lookups: the link between software and DNS servers. It’s a server-to-server protocol."
Been running DNS myself since about 1997(both hosting authoritative BIND9 servers as well as hosting domains with Dyn in the last decade or so), though no DNSSEC.
Jim Mitchell
What does
There's also a lot of reliance on distant state invariants, which is unsafe even by C standards.
mean?
Well......
C strikes again.
Color me surprised.....