SecureState Blog

Read SecureState's award winning blog.

New Critical OpenSSL Vulnerability on the Heels of Heartbleed

Earlier today, OpenSSL reported a fix for a vulnerability which might enable an attacker to decrypt and modify communications that use OpenSSL for their SSL implementations (CVE-2014-0224). In order for this attack to be successful, an attacker must insert themselves into the communication path of the client attempting to make a secure connection using SSL and the server which supports such a connection.

Additionally, both the client and the server must be using OpenSSL for their SSL implementation and these versions of OpenSSL must contain this particular vulnerability. This vulnerability is the result of a broken process around the sequence of events that OpenSSL uses in order to establish a connection over SSL. SSL makes use of both symmetric encryption (the two parties know a shared secret) and asymmetric encryption (public key cryptography).

When a client tries to establish an SSL connection with a server, the client will use the server’s public key (which should be publically accessible to everyone) to encrypt data that only the server can decrypt with its private key (which the server must keep secret at all costs). The server can use its private key to decrypt everything that is encrypted with its public key. In the context of SSL, this asymmetric cryptography is used for sharing a secret between the client and the server. Once a shared Master Secret is exchanged, the client sends a “Change cipher spec” notification to the server, which essentially notifies the server, that from that point on, all encryption will occur using the new Master Secret.

However, vulnerable versions of OpenSSL do not verify that a shared Master Secret has been set, before accepting the “Change cipher spec” notification. Because of this, an attacker could send “Change cipher spec” notifications to the vulnerable machines before the Shared Master Secret is ever set. This means that the symmetric keys will be generated with an empty Master Secret, and allow the attacker to encrypt, and modify all traffic in transit between the two parties.

It should be noted that all client versions of OpenSSL are vulnerable, but only servers running OpenSSL 1.0.1 and 1.0.2-beta1 are confirmed to be vulnerable. However, as a precaution, all OpenSSL versions prior to OpenSSL 1.0.1 should be upgraded as well. Browsers like Internet Explorer, FireFox and Safari do not use OpenSSL for establishing SSL/TLS connections, so this vulnerable does not affect those who use these browsers for communication over SSL.

However, Android’s browser and the version of Chrome that runs on Android does use OpenSSL. Although it is not yet confirmed whether or not these browsers contain this vulnerability, as a precaution it is advised to use a different browser until it can be confirmed, or until patches are released for these browsers that addresses this vulnerability. Additionally, organizations that are using OpenSSL for implementing SSL on their servers should upgrade their version of OpenSSL as soon as possible. The recommended upgrades are listed as follows:

–> OpenSSL 0.9.8 SSL/TLS users are advised to upgrade to 0.9.8za

–> OpenSSL 1.0.0 SSL/TLS users are advised to upgrade to 1.0.0m

–> OpenSSL 1.0.1 SSL/TLS users are advised to upgrade to 1.0.1h