CVE-2024-0553 - Timing Side-Channel Attack Still Possible in GnuTLS RSA-PSK Key Exchange

In early 2024, security researchers uncovered a vulnerability in the popular GnuTLS library, documented as CVE-2024-0553. This bug is especially important because it shows that the fix for a previous bug, CVE-2023-5981, wasn't enough. If you use GnuTLS in your systems—especially with RSA-PSK key exchange—this is a must-read. In this article, I’ll explain what the vulnerability is, show you what the code looks like, and discuss how bad guys might exploit it.

The Basics

GnuTLS is a widely used open-source library for TLS and SSL protocols. One way it establishes secure connections is with the RSA-PSK ClientKeyExchange mechanism. Here, the server receives an encrypted key from the client. The server decrypts it using its RSA private key. Normally, attackers shouldn’t be able to tell if they're guessing things right or wrong. But with this bug, they can use timing attacks to sniff out private information.

The Problem

The vulnerability is a classic case of a timing side-channel attack. When GnuTLS processes specially crafted (malformed) ciphertexts, it takes a different amount of time depending on whether the ciphertext is correct (valid padding) or malformed (invalid padding). By measuring these timing differences, remote attackers can slowly gather clues about the server’s private key or sensitive session data.

Even worse, the patch for CVE-2023-5981 didn't fully close the hole. Thus, CVE-2024-0553 was issued as an "incomplete resolution".

RSA-PSK Key Exchange

Without getting too deep into cryptography, RSA-PSK is a method where the client and server agree on a shared secret. The client sends this secret, encrypted using the server’s RSA public key, in a ClientKeyExchange message.

Checks the PKCS#1 v1.5 padding.

3. If padding is invalid, the handshake should *fail* in a way that gives away as little extra info as possible.

The Flaw in GnuTLS

In the actual GnuTLS code, the time it took for the server to process a message depended on whether the padding was correct. Here’s a simplified code snippet to demonstrate the issue:

// Pseudo-code representation
int decrypt_client_key_exchange(ciphertext) {
    decrypted = rsa_decrypt(ciphertext);

    if (!check_pkcs1_v15_padding(decrypted)) {
        // Invalid padding
        return error;
    }

    // Padding valid, continue handshake
    process_key(decrypted);
    return success;
}

In the real world, the check_pkcs1_v15_padding function is *not* constant-time. So attackers can send hundreds or thousands of guesses and measure the time it takes GnuTLS to respond. That forms the basis of a timing attack.

Exploiting CVE-2024-0553: How Bad Guys Could Steal Keys

Step 1: The attacker sends a flood of ClientKeyExchange messages, each with a different malformed ciphertext.

Step 2: The attacker times how long GnuTLS takes to reject each message.

Step 3: Over many, many queries, patterns emerge. The attacker can infer bits about the padding—eventually, about the private key.

Step 4: If successful and patient, the attacker recovers enough info to decrypt session data—possibly even impersonate clients or servers!

Here’s a mock-up to show how a timing attack could be orchestrated

import time
import socket

def send_bad_ciphertext(data):
    sock = socket.create_connection(('victim_server', 443))
    sock.send(data)
    start = time.time()
    response = sock.recv(1024)
    end = time.time()
    sock.close()
    return end - start

for guess in range(256):
    fake_ciphertext = make_fake_ciphertext(guess)
    duration = send_bad_ciphertext(fake_ciphertext)
    print(f"Guess={guess} Response Time={duration:.5f}s")
    # Store results, analyze later

Disclaimer: This is a simplified example for educational purposes only.

How Is CVE-2024-0553 Different from CVE-2023-5981?

- CVE-2023-5981: First identified the timing issue in GnuTLS but the patch didn't fully prevent timing leaks.
- CVE-2024-0553: Recognizes the incomplete fix; the timing side channel *still* exists in certain GnuTLS versions.

If you can, disable RSA-PSK cipher suites until a new, comprehensive patch lands.

- Always keep software updated. Monitor the official GnuTLS CVE tracker and look for upcoming patches.

Official References & More Reading

- GnuTLS Security Advisory
- NVD Entry for CVE-2024-0553
- NVD Entry for CVE-2023-5981
- Padding Oracle Attacks (the broader class of issue)

Final Thoughts

CVE-2024-0553 highlights how tricky it can be to fully close subtle cryptographic bugs. Timing leaks are dangerous, especially for widely deployed libraries like GnuTLS. If you work with these tools, stay patched and consider using only modern cipher suites that are less likely to have these ancient pitfalls.

Timeline

Published on: 01/16/2024 12:15:45 UTC
Last modified on: 03/25/2024 18:15:08 UTC