CVE-2023-5981

What it actually does

Timing side-channel in RSA-PSK ClientKeyExchange handling leaks whether PKCS#1 v1.5 padding is valid, enabling an attacker to distinguish correct versus malformed ciphertexts via response-time differences.

Why it matters to the business

Attackers may recover RSA-encrypted session keys or other sensitive material, leading to decryption of protected communications and exposure of confidential data in transit.

How an attack unfolds

An attacker repeatedly sends specially crafted RSA-PSK ClientKeyExchange messages containing malformed padding to a vulnerable server and measures the slight differences in response latency to perform an adaptive chosen-ciphertext attack that gradually recovers the plaintext.

How to fix it

Upgrade GnuTLS to the latest stable release that eliminates the timing difference; rebuild and restart all dependent services; disable RSA-PSK cipher suites if the upgrade cannot be performed immediately.

How to confirm the fix worked

Compare response-time distributions for valid versus invalid PKCS#1 v1.5 padding after the update; confirm the GnuTLS version string no longer matches the vulnerable range and re-run timing tests to verify constant-time behavior.

Typical attack path

1. Scan for services using GnuTLS with RSA-PSK key exchange enabled
2. Send multiple probe ClientKeyExchange records with varying padding errors
3. Record high-resolution response times for each probe
4. Use timing oracle to iteratively decrypt RSA ciphertext and recover premaster secret
5. Derive session keys and decrypt subsequent traffic

How to detect it

Examine application and TLS handshake logs for unusually high volumes of RSA-PSK ClientKeyExchange messages from single sources; correlate with any observed timing anomalies or failed handshakes that may indicate probing.

What your security team should do

• Prioritize patching GnuTLS on all externally reachable systems within the next maintenance window
• Review deployed applications for RSA-PSK usage and replace with modern key-exchange methods where feasible
• Add GnuTLS version checks to vulnerability scanning policies
• Monitor for any public exploit code that targets this timing oracle