CVE-2023-4421

What it actually does

Timing side-channel in PKCS#1 v1.5 padding validation leaks both overall padding correctness and plaintext length, enabling recovery of RSA-encrypted messages or signature forgery via chosen-ciphertext attacks.

Why it matters to the business

Attackers could decrypt previously captured TLS sessions that used RSA key exchange or forge signatures with the victim's private key, undermining encrypted communications and code or message authenticity across any product using the vulnerable NSS library.

How an attack unfolds

An attacker intercepts an RSA-encrypted TLS session, then sends thousands of carefully crafted ciphertexts to the target NSS instance while measuring response timing differences; the leaked padding validity and length information is used to mount a Bleichenbacher-style oracle attack that eventually recovers the session key or forges a signature.

How to fix it

Upgrade Mozilla NSS to version 3.61 or later, which implements the implicit-rejection (constant-time) padding check; rebuild and redeploy all dependent applications and libraries.

How to confirm the fix worked

Verify installed NSS version is 3.61 or higher; run the Marvin Attack test vectors or constant-time padding test suites against the library; confirm no timing variance is observable across valid/invalid PKCS#1 v1.5 inputs.

Typical attack path

1. Intercept RSA-encrypted ciphertext (e.g., TLS handshake)
2. Send large volume of attacker-chosen probe ciphertexts to vulnerable NSS endpoint
3. Measure timing side-channel responses to classify padding validity and length
4. Iteratively recover plaintext bytes or construct a valid signature forgery

How to detect it

Search application and TLS termination logs for unusually high rates of RSA decryption or signature verification calls returning padding errors; correlate with external network traffic showing repeated connections from the same source sending malformed ciphertexts.

What your security team should do

• Immediately inventory all systems and containers using NSS and schedule upgrade to 3.61+
• Replace RSA key exchange with ECDHE or other forward-secret cipher suites where possible
• Add monitoring for high volumes of RSA decryption operations with invalid padding
• Review and rotate any long-lived RSA private keys that may have been exposed to the vulnerability window