Vulnerability Note VU#888801

Vlastimil Klíma, Ondřej Pokorný, and Tomáš Rosa have published a research paper describing a modified Bleichenbacher attack against RSA-based SSL/TLS applications. As in Bleichenbacher, the new attack uses side channel information from error messages and seeks to discover the premaster secret that is used as a basis for SSL/TLS session keys.

The Bleichenbacher attack (CA-1998-07) is computationally feasible against RSA-based applications that use Public-Key Cryptography Standard (PKCS) #1 v1.5 and return distinctive errors when the premaster secret in the Client hello message is not properly formatted. By sending a large number of chosen ciphertexts (premaster secrets) and monitoring the applications' responses, an attacker can discover the correct premaster secret for a given SSL/TLS session. With the premaster secret for a previously captured SSL/TLS session, the attacker can generate the correct master secret and session keys and decrypt the captured session. For more information about the Bleichenbacher attack, see Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1, RSA Laboratories Bulletin Number 7, and CERT Advisory CA-1998-07.

A widely accepted defense against the Bleichenbacher attack is for an RSA/PKCS #1 application to discard a malformed premaster secret, replace it with a random value, and proceed to generate a master secret and session keys. Since the client and server use different values for the premaster secret, they will generate different session keys, and the SSL/TLS session will fail. Note that the server must not provide a response that is distinguishable based on syntax (i.e. "Bad PKCS #1 format") or time (i.e. sending an error message immediately after discovering that the premaster secret is malformed).

The Klíma-Pokorný-Rosa attack exploits server responses to an incorrect or unexpected SSL/TLS version number that is included as part of the premaster secret (RFC 2246 section 7.4.7.1). If a server decrypts a properly formatted PKCS #1 premaster secret and discovers that the SSL/TLS version number is not what was expected, the server may immediately send an error message ("Bad SSL/TLS version number"). The authors term a server that exhibits this behavior a "bad version oracle (BVO)." Instead of using an error response to improper PKCS #1 formatting, this new attack uses an error response to an incorrect SSL/TLS version number. Klíma-Pokorný-Rosa have also introduced some optimizations to the Bleichenbacher attack, partly due to the SSL/TLS standard only using a subset of the PKCS #1 v1.5 format (section 3.2). This allows an attacker to search less space for the correct premaster secret.

This attack is feasible using widely available hardware. Under ideal laboratory conditions (100Mbps closed network, unloaded server with 2 X Pentium III 1.4GHz CPUs and 1 GB of RAM, Red Hat Linux 7.2, Apache 1.3.27/mod_ssl), the median time required for a successful attack is around 54.7 hours (~13 million guesses).

Since the SSL/TLS version number is a protocol-specific extension of the PKCS #1 format, other applications that use RSA/PKCS #1 to exchange keying information are not vulnerable to this attack. In particular, SSH1 using RSA only encrypts a session key. No version or other information is included. IKE authenticated with public key encryption is further protected by an ephemeral Diffe-Hellman exchange. For specific vendor information, see the Systems Affected section below.

An attacker who is able to capture an encrypted SSL/TLS session and query the server while it is using the same private RSA key that was used for the captured session could decrypt the captured session. An attacker could also forge a signature that appeared to be from the server (section 3.4).

Upgrade or Patch

Upgrade or apply a patch as specified by your vendor. In order to defeat this specific attack, an SSL/TLS server must not respond distinctively when a premaster secret sent by the client contains an incorrect or unexpected SSL/TLS version number. The paper recommends that an SSL/TLS server always replace the client-provided version number with the expected version number as determined from either the Client hello or Server hello messages (section 6.2).

Manage private keys

Use different private keys for different applications and servers and change keys as appropriate for your site and security policy. An attacker cannot decrypt a premaster secret encrypted with one RSA key by querying a server that uses a different key.

Monitor RSA applications and servers for signs of attack. In the case of an attack against SSL/TLS web servers, logs may show a relatively high number of network connections and failed attempts to establish SSL/TLS sessions. Depending on baseline performance, servers may show increased CPU usage or an above average number of network connections.