GnuTLS patches huge security hole that hung around for two years – worse than Heartbleed, says Google cryptoboffin
(2020/06/10)
- Reference: 1591768867
- News link: https://www.theregister.co.uk/2020/06/10/gnutls_patches_security_hole/
- Source link:
GnuTLS, a widely used open source library implementing Transport Layer Security, last week fixed a bug that had been hiding in the code for almost two years that made resumed TLS 1.3 sessions vulnerable to attack.
The TLS handshake requires two round-trips between client and server to establish a secure connection. Session tickets provide a way to resume previously established connections with only one round-trip. But this convenience comes at a cost – it's less secure, as [1]described by Google cryptographer Filippo Valsorda.
[2]The flaw allowed GnuTLS servers to use session tickets issued during a previous secure TLS 1.3 session without accessing the function that generates secret keys, gnutls_session_ticket_key_generate() . An attacker capable of exploiting this vulnerability could bypass authentication under TLS 1.3 and could recover previous conversations under TLS 1.2.
The bug, introduced in GnuTLS 3.6.4 (Sep. 24, 2018), was fixed in GnuTLS 3.6.14 (June 3, 2020).
[3]Via Twitter , Andrew Ayer, founder of SSLMate, laid into the GnuTLS code for devising a complicated key rotation system that doesn't actually work.
"All their 'rotation' did was add a vulnerability," he said.
Had a bad weekend? Probably, if you're a Sectigo customer, after root cert expires and online chaos ensues [4]READ MORE
Nikos Mavrogiannopoulos, a security engineer at Red Hat and contributor to GnuTLS, expressed reluctance to engage in a Twitter crypto-fight but came to the defense of the project anyway.
"GnuTLS is a library, and does not set the master key; the master key is set by applications," he [5]explained . "We figured out that not all applications rotate keys, so this mechanism was introduced to protect these applications."
"In that context the rotation protects from the key being reused; it does not protect the key if extracted from the application, which was not our concern," he said.
Ayer has been critical of GnuTLS in the past, referring to it as a "clownish" TLS implementation in a blog post about [6]the expiration of Sectigo's AddTrust legacy root certificate , which affected GnuTLS.
Others echoed his disdain for GnuTLS, with some [7]arguing for its removal as a dependency. "Never use GnuTLS," [8]quipped Thomas H. Ptacek, a security researcher and founder of Matasano Security. "...we are enforcing a strict no GnuTLS policy," [9]said Michael Gebetsroither, founder of consultancy mgIT. And Filippo Valsorda [10]said , "PSA: don't rely on GnuTLS, please."
"For scale, this GnuTLS vulnerability is considerably worse than Heartbleed," Valsorda [11]said in a subsequent post. "If you use Linux distributions with GNU tendencies, you might want to check your dependency trees."
Along those lines, Debian, Fedora, and Gentoo Linux distributions have issued [12]security advisories .
Danny McClanahan, a software engineer at Twitter who works with open source software, [13]fired back at infosec professionals for using his company's social media site to disparage GnuTLS and to discourage people using it rather than contributing to the software project and make it better.
"Everyone’s trying to sell something and nobody cares about free software…" McClanahan [14]lamented , who went on to [15]chide Google for hiring expensive security engineers but not offering financial support to the projects they criticize.
The Register asked Ayer about the harsh assessment he and others have offered for GnuTLS and whether that animus might be motivated by interest in a competing TLS project. He said he doesn't contribute to other TLS libraries and he expressed doubt about the suggestion of ulterior motives among others slamming the software.
"I think this recent vulnerability is a really good example of why security professionals have a distaste for GnuTLS," he said in reply.
"The GnuTLS developers set out to improve session ticket encryption key (STEK) rotation, but they seem to have completely misunderstood the problem with STEKs because they came up with a complicated homebrew solution that doesn't actually solve any problems with STEKs."
"Their design wouldn't have made STEKs worse had they implemented it correctly, but since it's complicated they did make a mistake implementing it, leading to the vulnerability," he explained.
"And while making a mistake implementing something useful is forgivable, making a mistake implementing something useless is completely avoidable. And the fact that they were implementing something useless indicates they don't understand the cryptography, which is a problem for the authors of a TLS library." ®
Sponsored: [16]Google Security Whitepaper
[1] https://blog.filippo.io/we-need-to-talk-about-session-tickets/
[2] https://gitlab.com/gnutls/gnutls/-/issues/1011
[3] https://twitter.com/__agwa/status/1270076719819558912?s=20
[4] https://www.theregister.com/2020/06/02/sectigo_root_cert_expires/
[5] https://twitter.com/nmav_t/status/1270263409137913857?s=20
[6] https://www.theregister.com/2020/06/02/sectigo_root_cert_expires/
[7] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962508
[8] https://twitter.com/tqbf/status/1270200201421238273?s=20
[9] https://twitter.com/mgeb/status/1270466541537169408?s=20
[10] https://twitter.com/FiloSottile/status/1270061316368224256?s=20
[11] https://twitter.com/FiloSottile/status/1270115515378384897?s=20
[12] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13777
[13] https://twitter.com/hipsterelectron/status/1270176331448250368?s=20
[14] https://twitter.com/hipsterelectron/status/1270176336489799681?s=20
[15] https://twitter.com/hipsterelectron/status/1270185914937929728?s=20
[16] https://go.theregister.com/tl/1956/-8471/google-security-whitepaper?td=wptl1956
The TLS handshake requires two round-trips between client and server to establish a secure connection. Session tickets provide a way to resume previously established connections with only one round-trip. But this convenience comes at a cost – it's less secure, as [1]described by Google cryptographer Filippo Valsorda.
[2]The flaw allowed GnuTLS servers to use session tickets issued during a previous secure TLS 1.3 session without accessing the function that generates secret keys, gnutls_session_ticket_key_generate() . An attacker capable of exploiting this vulnerability could bypass authentication under TLS 1.3 and could recover previous conversations under TLS 1.2.
The bug, introduced in GnuTLS 3.6.4 (Sep. 24, 2018), was fixed in GnuTLS 3.6.14 (June 3, 2020).
[3]Via Twitter , Andrew Ayer, founder of SSLMate, laid into the GnuTLS code for devising a complicated key rotation system that doesn't actually work.
"All their 'rotation' did was add a vulnerability," he said.
Had a bad weekend? Probably, if you're a Sectigo customer, after root cert expires and online chaos ensues [4]READ MORE
Nikos Mavrogiannopoulos, a security engineer at Red Hat and contributor to GnuTLS, expressed reluctance to engage in a Twitter crypto-fight but came to the defense of the project anyway.
"GnuTLS is a library, and does not set the master key; the master key is set by applications," he [5]explained . "We figured out that not all applications rotate keys, so this mechanism was introduced to protect these applications."
"In that context the rotation protects from the key being reused; it does not protect the key if extracted from the application, which was not our concern," he said.
Ayer has been critical of GnuTLS in the past, referring to it as a "clownish" TLS implementation in a blog post about [6]the expiration of Sectigo's AddTrust legacy root certificate , which affected GnuTLS.
Others echoed his disdain for GnuTLS, with some [7]arguing for its removal as a dependency. "Never use GnuTLS," [8]quipped Thomas H. Ptacek, a security researcher and founder of Matasano Security. "...we are enforcing a strict no GnuTLS policy," [9]said Michael Gebetsroither, founder of consultancy mgIT. And Filippo Valsorda [10]said , "PSA: don't rely on GnuTLS, please."
"For scale, this GnuTLS vulnerability is considerably worse than Heartbleed," Valsorda [11]said in a subsequent post. "If you use Linux distributions with GNU tendencies, you might want to check your dependency trees."
Along those lines, Debian, Fedora, and Gentoo Linux distributions have issued [12]security advisories .
Danny McClanahan, a software engineer at Twitter who works with open source software, [13]fired back at infosec professionals for using his company's social media site to disparage GnuTLS and to discourage people using it rather than contributing to the software project and make it better.
"Everyone’s trying to sell something and nobody cares about free software…" McClanahan [14]lamented , who went on to [15]chide Google for hiring expensive security engineers but not offering financial support to the projects they criticize.
The Register asked Ayer about the harsh assessment he and others have offered for GnuTLS and whether that animus might be motivated by interest in a competing TLS project. He said he doesn't contribute to other TLS libraries and he expressed doubt about the suggestion of ulterior motives among others slamming the software.
"I think this recent vulnerability is a really good example of why security professionals have a distaste for GnuTLS," he said in reply.
"The GnuTLS developers set out to improve session ticket encryption key (STEK) rotation, but they seem to have completely misunderstood the problem with STEKs because they came up with a complicated homebrew solution that doesn't actually solve any problems with STEKs."
"Their design wouldn't have made STEKs worse had they implemented it correctly, but since it's complicated they did make a mistake implementing it, leading to the vulnerability," he explained.
"And while making a mistake implementing something useful is forgivable, making a mistake implementing something useless is completely avoidable. And the fact that they were implementing something useless indicates they don't understand the cryptography, which is a problem for the authors of a TLS library." ®
Sponsored: [16]Google Security Whitepaper
[1] https://blog.filippo.io/we-need-to-talk-about-session-tickets/
[2] https://gitlab.com/gnutls/gnutls/-/issues/1011
[3] https://twitter.com/__agwa/status/1270076719819558912?s=20
[4] https://www.theregister.com/2020/06/02/sectigo_root_cert_expires/
[5] https://twitter.com/nmav_t/status/1270263409137913857?s=20
[6] https://www.theregister.com/2020/06/02/sectigo_root_cert_expires/
[7] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962508
[8] https://twitter.com/tqbf/status/1270200201421238273?s=20
[9] https://twitter.com/mgeb/status/1270466541537169408?s=20
[10] https://twitter.com/FiloSottile/status/1270061316368224256?s=20
[11] https://twitter.com/FiloSottile/status/1270115515378384897?s=20
[12] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13777
[13] https://twitter.com/hipsterelectron/status/1270176331448250368?s=20
[14] https://twitter.com/hipsterelectron/status/1270176336489799681?s=20
[15] https://twitter.com/hipsterelectron/status/1270185914937929728?s=20
[16] https://go.theregister.com/tl/1956/-8471/google-security-whitepaper?td=wptl1956
One rule for them...
RyokuMas
And where, oh Google, is the usual caveat of "you've got 90 days to fix this before we tell the world"?
... or maybe it's because you don't have anything that competes with this directly???
One of the advantages of open source..
Lunatic Looking For Asylum
Allegedly is that any bugs etc. are visible and in the open so in theory lots of eyes will find them and report them or fix them. For this to be around for a few years means that this possibly has not been seen/noticed/exploited until now. Why have all these experts not noticed and called the developers out before now ? I'm pretty certain that GNU TLS is not developed by a lone individual in a shed somewhere, it's a fairly large collaborative operation so there will already have been a lot of eyes and project comms on the development of this feature so the herd must have thought it was OK, it wasn't just some rogue/lone developer's flawed thinking.
There is no mention of exploitations in the wild and the patches have been applied and released (I got Debian Security Notices on Saturday) so it's already been mitigated against.
At least it has been found, we have no ideas and no chances of finding out what nasties thare are in [BIGMONOLITHIC] INC.s libraries which we of course trust implicitly.
Well said...
"McClanahan lamented, who went on to chide Google for hiring expensive security engineers but not offering financial support to the projects they criticize."
Couldn't be put any better.