GnuTLS patches huge security hole that hung around for two years – worse than Heartbleed, says Google cryptoboffin

Maybe it's time to get it gone

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 described by Google cryptographer Filippo Valsorda.

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).

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


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 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 the expiration of Sectigo's AddTrust legacy root certificate, which affected GnuTLS.

Others echoed his disdain for GnuTLS, with some arguing for its removal as a dependency. "Never use GnuTLS," quipped Thomas H. Ptacek, a security researcher and founder of Matasano Security. "...we are enforcing a strict no GnuTLS policy," said Michael Gebetsroither, founder of consultancy mgIT. And Filippo Valsorda said, "PSA: don't rely on GnuTLS, please."

"For scale, this GnuTLS vulnerability is considerably worse than Heartbleed," Valsorda 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 security advisories.

Danny McClanahan, a software engineer at Twitter who works with open source software, 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 lamented, who went on to 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." ®

Other stories you might like

  • SEC probes Musk for not properly disclosing Twitter stake
    Meanwhile, social network's board rejects resignation of one its directors

    America's financial watchdog is investigating whether Elon Musk adequately disclosed his purchase of Twitter shares last month, just as his bid to take over the social media company hangs in the balance. 

    A letter [PDF] from the SEC addressed to the tech billionaire said he "[did] not appear" to have filed the proper form detailing his 9.2 percent stake in Twitter "required 10 days from the date of acquisition," and asked him to provide more information. Musk's shares made him one of Twitter's largest shareholders. The letter is dated April 4, and was shared this week by the regulator.

    Musk quickly moved to try and buy the whole company outright in a deal initially worth over $44 billion. Musk sold a chunk of his shares in Tesla worth $8.4 billion and bagged another $7.14 billion from investors to help finance the $21 billion he promised to put forward for the deal. The remaining $25.5 billion bill was secured via debt financing by Morgan Stanley, Bank of America, Barclays, and others. But the takeover is not going smoothly.

    Continue reading
  • Cloud security unicorn cuts 20% of staff after raising $1.3b
    Time to play blame bingo: Markets? Profits? Too much growth? Russia? Space aliens?

    Cloud security company Lacework has laid off 20 percent of its employees, just months after two record-breaking funding rounds pushed its valuation to $8.3 billion.

    A spokesperson wouldn't confirm the total number of employees affected, though told The Register that the "widely speculated number on Twitter is a significant overestimate."

    The company, as of March, counted more than 1,000 employees, which would push the jobs lost above 200. And the widely reported number on Twitter is about 300 employees. The biz, based in Silicon Valley, was founded in 2015.

    Continue reading
  • Talos names eight deadly sins in widely used industrial software
    Entire swaths of gear relies on vulnerability-laden Open Automation Software (OAS)

    A researcher at Cisco's Talos threat intelligence team found eight vulnerabilities in the Open Automation Software (OAS) platform that, if exploited, could enable a bad actor to access a device and run code on a targeted system.

    The OAS platform is widely used by a range of industrial enterprises, essentially facilitating the transfer of data within an IT environment between hardware and software and playing a central role in organizations' industrial Internet of Things (IIoT) efforts. It touches a range of devices, including PLCs and OPCs and IoT devices, as well as custom applications and APIs, databases and edge systems.

    Companies like Volvo, General Dynamics, JBT Aerotech and wind-turbine maker AES are among the users of the OAS platform.

    Continue reading

Biting the hand that feeds IT © 1998–2022