CVE-2024-0553 Overview
A timing side-channel vulnerability was discovered in GnuTLS affecting the RSA-PSK key exchange mechanism. The vulnerability exists because response times to malformed ciphertexts in RSA-PSK ClientKeyExchange messages differ from response times of ciphertexts with correct PKCS#1 v1.5 padding. This timing discrepancy can be exploited by a remote attacker to perform a side-channel attack, potentially leading to the leakage of sensitive cryptographic data.
This vulnerability is designated as an incomplete resolution for CVE-2023-5981, indicating that previous mitigation efforts did not fully address the underlying timing oracle issue.
Critical Impact
Remote attackers can exploit timing differences in RSA-PSK key exchange to extract sensitive cryptographic material through network-based side-channel attacks, compromising the confidentiality of encrypted communications.
Affected Products
- GNU GnuTLS (all versions prior to patch)
- Fedora 39
- Red Hat Enterprise Linux 8.0 and 9.0
Discovery Timeline
- January 16, 2024 - CVE-2024-0553 published to NVD
- November 21, 2024 - Last updated in NVD database
Technical Details for CVE-2024-0553
Vulnerability Analysis
This vulnerability falls under CWE-203 (Observable Discrepancy), a class of weaknesses where the system's behavior differs observably based on internal state or processing. In the context of GnuTLS, the RSA-PSK key exchange implementation processes malformed and correctly padded ciphertexts in measurably different amounts of time.
The RSA-PSK cipher suites combine RSA encryption with Pre-Shared Key (PSK) authentication, providing an additional layer of security. However, the PKCS#1 v1.5 padding validation within GnuTLS introduces timing variations that can be measured by an attacker observing network response times. These timing differences, while subtle, provide enough information for a determined attacker to distinguish between valid and invalid padding, enabling a classic Bleichenbacher-style attack against RSA encryption.
The impact is primarily on confidentiality, as successful exploitation allows attackers to potentially decrypt intercepted TLS sessions or recover pre-master secrets used in key derivation.
Root Cause
The root cause lies in the non-constant-time implementation of PKCS#1 v1.5 padding validation during RSA-PSK ClientKeyExchange processing. When the GnuTLS library decrypts and validates incoming ciphertexts, the code paths for handling correctly padded versus incorrectly padded data execute in different amounts of time. This represents an incomplete fix from CVE-2023-5981, where the initial timing mitigation did not comprehensively address all code paths that process RSA-encrypted pre-master secrets.
Attack Vector
The attack is network-exploitable and requires no authentication or user interaction. An attacker positioned to observe or intercept TLS handshakes can:
- Capture encrypted RSA-PSK ClientKeyExchange messages from legitimate sessions
- Send crafted ciphertexts to the vulnerable server while precisely measuring response times
- Use statistical analysis of timing variations to determine padding validity
- Iteratively refine the attack to decrypt the pre-master secret
- Derive session keys and decrypt captured traffic
The attack is practical in scenarios where an attacker can observe network traffic and send modified handshake messages, such as man-in-the-middle positions or shared network environments.
Detection Methods for CVE-2024-0553
Indicators of Compromise
- Unusual patterns of TLS handshake failures or retries from single sources
- High volumes of RSA-PSK ClientKeyExchange messages with varied ciphertext values
- Suspicious timing analysis attempts manifesting as rapid sequential connection attempts
- Network traffic patterns consistent with Bleichenbacher attack probing
Detection Strategies
- Monitor TLS handshake logs for abnormal failure rates in RSA-PSK cipher suite negotiations
- Implement network intrusion detection rules to identify rapid TLS handshake attempts from single IP addresses
- Deploy application-layer monitoring to flag unusual patterns in ClientKeyExchange message processing
- Analyze server-side metrics for timing anomalies during cryptographic operations
Monitoring Recommendations
- Enable detailed TLS handshake logging on servers using GnuTLS
- Configure SIEM alerts for patterns matching cryptographic oracle attacks
- Monitor for reconnaissance activity targeting TLS configuration endpoints
- Implement rate limiting on TLS handshake attempts from individual sources
How to Mitigate CVE-2024-0553
Immediate Actions Required
- Update GnuTLS to the latest patched version immediately on all affected systems
- Review and update dependent packages that bundle or link against GnuTLS
- Consider disabling RSA-PSK cipher suites if not required for operations
- Audit TLS configurations to prefer ECDHE-based key exchanges where possible
Patch Information
Security patches are available from multiple vendors. Red Hat has released several security errata addressing this vulnerability:
- RHSA-2024:0533 - Initial Red Hat Enterprise Linux patches
- RHSA-2024:0627 - Additional RHEL updates
- RHSA-2024:0796 - Extended coverage patches
Fedora users should apply updates through the standard package management system. The upstream fix is tracked in GnuTLS Issue #1522. Debian LTS users should refer to the Debian LTS Announcement for applicable updates.
Workarounds
- Disable RSA-PSK cipher suites in GnuTLS configuration if not operationally required
- Configure servers to prioritize ECDHE-based cipher suites over RSA key exchange variants
- Implement network segmentation to limit attacker positioning for timing attacks
- Deploy TLS termination proxies with patched cryptographic libraries in front of vulnerable systems
# Example: Disable RSA-PSK cipher suites in GnuTLS priority string
# Add to server configuration to exclude vulnerable cipher suites
gnutls-cli --priority "SECURE256:-RSA-PSK-ALL" --list
# Or configure in application TLS settings:
# Priority string: "NORMAL:-RSA-PSK-ALL:-RSA-PSK-AES-128-CBC-SHA256:-RSA-PSK-AES-256-CBC-SHA384"
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
