CVE-2023-5981: GNU GnuTLS Information Disclosure Flaw

CVE-2023-5981 Overview

CVE-2023-5981 is a timing side-channel vulnerability discovered in GnuTLS, the widely-used TLS library implementation. The vulnerability exists in the RSA-PSK (Pre-Shared Key) handshake processing where response times to malformed ciphertexts differ from response times of ciphertexts with correct PKCS#1 v1.5 padding. This timing discrepancy can be exploited by a network-based attacker to potentially recover sensitive cryptographic material through statistical analysis of response times.

Critical Impact
This timing attack vulnerability could allow remote attackers to decrypt TLS-protected communications by exploiting observable differences in RSA-PSK decryption processing times, potentially compromising the confidentiality of encrypted sessions.

Affected Products

GNU GnuTLS 1.5.0 and later versions
Red Hat Linux 8.0 and 9.0
Fedora 37 and 38

Discovery Timeline

2023-11-28 - CVE-2023-5981 published to NVD
2025-11-04 - Last updated in NVD database

Technical Details for CVE-2023-5981

Vulnerability Analysis

This vulnerability is classified as CWE-203 (Observable Discrepancy), commonly known as a timing side-channel attack. The flaw resides in GnuTLS's RSA-PSK ClientKeyExchange message processing, where the decryption routine exhibits different execution times depending on whether the submitted ciphertext contains valid or invalid PKCS#1 v1.5 padding.

In a properly implemented RSA decryption routine, the processing time should be constant regardless of the input validity to prevent timing-based information leakage. However, the vulnerable GnuTLS implementation takes a different code path or performs different operations when encountering malformed padding versus correctly formatted ciphertexts. An attacker capable of measuring these timing differences over the network can systematically probe the server with crafted ciphertexts and statistically analyze the response times.

This class of vulnerability is similar to historical padding oracle attacks like Bleichenbacher's attack on PKCS#1 v1.5. While modern implementations typically include countermeasures against such attacks, subtle timing leaks can still provide enough information for a determined attacker to recover the pre-master secret used in TLS session establishment.

Root Cause

The root cause of this vulnerability is the lack of constant-time implementation in the RSA-PSK decryption handling within GnuTLS. When processing the ClientKeyExchange message during the TLS handshake, the library's PKCS#1 v1.5 padding validation routine introduces observable timing variations based on the padding validity. This violates fundamental cryptographic implementation principles that require side-channel resistant code paths for security-sensitive operations.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker positioned on the network path between a client and a vulnerable GnuTLS-based server can:

Intercept a legitimate TLS handshake and capture the encrypted pre-master secret
Send multiple crafted ClientKeyExchange messages with modified ciphertexts to the target server
Measure the response times with high precision to detect timing variations
Apply statistical analysis to the timing data to determine padding validity
Use adaptive chosen-ciphertext techniques to gradually recover the plaintext pre-master secret

This attack requires significant network measurements and computational resources, but is feasible against a persistent attacker with stable network access to the target.

Detection Methods for CVE-2023-5981

Indicators of Compromise

Unusual volume of TLS handshake failures or errors from specific source IPs
Repeated ClientKeyExchange messages from the same client within short time periods
Abnormal patterns in TLS session establishment timing metrics
High frequency of RSA-PSK cipher suite negotiation attempts

Detection Strategies

Monitor TLS handshake logs for patterns indicating systematic probing behavior
Implement anomaly detection for TLS session establishment timing distributions
Deploy network intrusion detection rules to identify Bleichenbacher-style attack patterns
Audit GnuTLS library versions across infrastructure to identify vulnerable deployments

Monitoring Recommendations

Enable detailed TLS handshake logging on servers using GnuTLS
Configure alerting for unusual spikes in TLS handshake failures
Implement network traffic analysis for detecting timing attack patterns
Regularly scan systems to verify GnuTLS has been updated to patched versions

How to Mitigate CVE-2023-5981

Immediate Actions Required

Update GnuTLS to the latest patched version immediately
Review and inventory all systems and applications using GnuTLS
Consider disabling RSA-PSK cipher suites if not operationally required
Prioritize patching internet-facing servers and services

Patch Information

Security patches have been released by multiple vendors. Refer to the following advisories for version-specific patch information:

GnuTLS Security Announcement GNUTLS-SA-2023-10-23 - Official GnuTLS security advisory
Red Hat Security Advisory RHSA-2024:0155 - Red Hat Enterprise Linux patches
Red Hat Security Advisory RHSA-2024:0319 - Additional Red Hat patches
Debian LTS Announcement - Debian security update
Fedora Package Announcements - Fedora security updates

For tracking and additional details, see Red Hat Bugzilla #2248445.

Workarounds

Disable RSA-PSK cipher suites in GnuTLS configuration if they are not required for your use case
Configure TLS to prefer non-RSA key exchange mechanisms such as ECDHE
Implement network-level rate limiting on TLS handshake attempts from individual sources
Consider deploying TLS-terminating proxies with patched implementations in front of vulnerable servers

bash

# Example: Configure GnuTLS priority string to exclude RSA-PSK cipher suites
# In your application or server configuration, set the priority string:
GNUTLS_PRIORITY="NORMAL:-RSA-PSK"

# For systems using /etc/crypto-policies (RHEL/Fedora):
# Update system-wide crypto policy to use stronger defaults
update-crypto-policies --set DEFAULT

# Verify GnuTLS version after patching
gnutls-cli --version