Home > Cyber News > CVE-2020-13777: Vulnerability in GnuTLS Hiding for 2 Years
CYBER NEWS

CVE-2020-13777: Vulnerability in GnuTLS Hiding for 2 Years

CVE-2020-13777 is a vulnerability in GnuTLS, a widely adopted, open source library that implements Transport Layer Security.

The vulnerability has been present in the library for nearly two years, making resumed TLS 1.3 sessions vulnerable to attack. The vulnerability, introduced in GnuTLS 3.6.4 in September, 2018 was addressed in GnuTLS 3.6.14 on June 3, 2020.

CVE-2020-13777 Explained

The bug allowed GnuTLS servers to utilize session tickets issued during a previous secure TLS 1.3 session, without accessing the function that generates secret keys:

gnutls_session_ticket_key_generate()

Attackers exploiting the CVE-2020-13777 vulnerability could circumvent authentication under TLS 1.3, thus recovering previous conversations under TLS 1.2.




According to security researcher known under the Airtower nickname:

GnuTLS servers are able to use tickets issued by each other without access to the secret key as generated by gnutls_session_ticket_key_generate(). This allows a MITM server without valid credentials to resume sessions with a client that first established an initial connection with a server with valid credentials. The issue applies to TLS 1.3, when using TLS 1.2 resumption fails as expected.

Related: [wplinkpreview url=”https://sensorstechforum.com/apple-microsoft-google-drop-support-tls1-0-tls1-1/”] Apple, Microsoft, and Google Drop Support for TLS 1.0 and TLS 1.1

The researcher first “noticed the issue with Ubuntu version 3.6.13-2ubuntu1, and reproduced it with a build from master as of 52e78f1e.”

Some security researchers have been arguing that GnuTLS should be removed as a dependency, with many voicing their disdain against the library, as pointed out by TheRegister.

The MITRE CVE dictionary gives the following description of the vulnerability:

GnuTLS 3.6.x before 3.6.14 uses incorrect cryptography for encrypting a session ticket (a loss of confidentiality in TLS 1.2, and an authentication bypass in TLS 1.3). The earliest affected version is 3.6.4 (2018-09-24) because of an error in a 2018-09-18 commit. Until the first key rotation, the TLS server always uses wrong data in place of an encryption key derived from an application.

There’s no known mitigation against the issue, RedHat advisory says.

Milena Dimitrova

An inspired writer and content manager who has been with SensorsTechForum since the project started. A professional with 10+ years of experience in creating engaging content. Focused on user privacy and malware development, she strongly believes in a world where cybersecurity plays a central role. If common sense makes no sense, she will be there to take notes. Those notes may later turn into articles! Follow Milena @Milenyim

More Posts

Follow Me:
Twitter

Leave a Comment

Your email address will not be published. Required fields are marked *

This website uses cookies to improve user experience. By using our website you consent to all cookies in accordance with our Privacy Policy.
I Agree