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:

1. Intercept a legitimate TLS handshake and capture the encrypted pre-master secret
2. Send multiple crafted ClientKeyExchange messages with modified ciphertexts to the target server
3. Measure the response times with high precision to detect timing variations
4. Apply statistical analysis to the timing data to determine padding validity
5. 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

# 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