HeartBleed … the Internet encryption earthquake

The first serious earthquake in the encryption world is the disclosure of the Heartbleed vulnerability (CVE-2014-0160), a serious flaw in the popular OpenSSL library that allows an attacker to reveal up to 64kB of memory to a connected client or server.

One month later, security researcher Robert David Graham has estimated that there are more than 300,000 servers still vulnerable to the flaw, as he explained in a blog post on Errata Security.

Millions of websites were vulnerable to a flaw in the OpenSSL code which they used to encrypt their communications over unsecured channels. Encrypted communications, mobile platforms, VPN and Tor networks are just a few samples of the extent of the impact of the Heartbleed vulnerability.

The OpenSSL project is managed by a worldwide community of volunteers, which provides support for the OpenSSL library and related documentation. OpenSSL is the most popular open source cryptographic library and TLS implementation for traffic encryption.

Figure – Codenomicon firm discovered Heartbleed flaw

“Bugs in a single software or library come and go and are fixed by new versions. However, this bug has left a large amount of private keys and other secrets exposed to the Internet. Considering the long exposure, ease of exploitation and attacks, leaving no trace this exposure should be taken seriously.”

But OpenSSL Heartbleed vulnerability was not an isolated case. Unfortunately, today The OpenSSL Foundation has issued software updates to patch a series of new vulnerabilities.

A new series of vulnerabilities in the OpenSSL library

According to the Open SSL Foundation, the new vulnerabilities discovered and fixed in the OpenSSL library are six, and at least two of them are considered critical. Fortunately, these vulnerabilities are not considerable as critical as the Heartbleed bug.

Still, the Foundation it is urging the users to update their implementation applying the available patches.

The patched versions 0.9.8za, 1.0.0m and 1.0.1h are available on the project website to download and The OpenSSL Foundation is urging companies to update their implementation as soon as possible.

CVE-2014-0224 Vulnerability – SSL/TLS MITM vulnerability

The first critical vulnerability in OpenSSL, coded CVE-2014-0224, is “CCS Injection” and it resides in the ChangeCipherSpec (CCS) request sent during the handshake. An attacker exploiting the flaw could perform a man-in-the-middle attack against the encrypted connection servers and clients. A man-in-the-middle attacks allows the attacker to intercept an encrypted connection which allows him to decrypt, read or manipulate the data in transit. In this specific case, the attack based on the exploitation of CVE-2014-0224 is possible only if both server and client are vulnerable.

In order for an attacker to exploit this flaw he must be able to intercept and modify packets off the wire.

How does this attack exactly work?

Red Hat team published a detailed explanation on its security blog. SSL/TLS sessions are initiated with the ClientHello and ServerHello handshake messages sent by client and server the respective side. In this phase the interlocutors negotiate the attributes of the session including the protocol version used, encryption protocol, encryption keys, Message Authentication Code (MAC) secrets and Initializaton Vectors (IV), as well as the extensions supported.

If, during communication, the client or the server decides to modify the encryption process strategies of the connection during the handshake stage, they operate setting in the proper way the ChangeCipherSpec (CCS) request. The CCS is a single packet which is sent by both the client and the server to notify that the subsequent records will be protected under the newly negotiated CipherSpec and keys to use.

“The ChangeCipherSpec message is sent during the handshake after the security parameters have been agreed upon, but before the verifying Finished message is sent,” states the standards (RFC 2246, RFC 5246).

In order to exploit this issue, a MITM attacker would effectively do the following:

  • Wait for a new TLS connection, followed by the ClientHello / ServerHello handshake messages.
  • Issue a CCS packet in both the directions, which causes the OpenSSL code to use a zero length pre master secret key. The packet is sent to both ends of the connection. Session Keys are derived using a zero length pre master secret key, and future session keys also share this weakness.
  • Renegotiate the handshake parameters.
  • The attacker is now able to decrypt or even modify the packets in transit.

OpenSSL clients are vulnerable in all versions of OpenSSL.
Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1.

Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution.

  • OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za.
  • OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m.
  • OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h.

The vulnerability was discovered by KIKUCHI Masashi (Lepidum Co. Ltd.) which explained that the bug had existed since the first release of OpenSSL library. The researcher reported it to OpenSSL Foundation on May 1th 2014 via JPCERT/CC.

The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch proposed by the researcher KIKUCHI Masashi. The patch operates by changing how it handles when CCS packets are received, “and how it handles zero length pre master secret values.”

CVE-2014-0221 Vulnerability- DTLS recursion flaw

The attacker could exploit the vulnerability by sending an invalid DTLS handshake to an OpenSSL DTLS client. In this way he will force the code to recurse, eventually crashing in a DoS attack.

The attack is effective only for software using OpenSSL as a DTLS client:

  • OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za
  • OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m.
  • OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h.

As explained by Wikipedia, the DTLS (Datagram Transport Layer Security) protocol provides communications privacy for datagram protocols. DTLS allows datagram-based applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.

This protocol is very common in communication application and VOIP, Chrome and Firefox also support DTLS for WebRTC (Web Real-Time Communication) for P2P file sharing and Voice/Video Chats.

The vulnerability was reported by Imre Rad (Search-Lab Ltd.)and it was reported to OpenSSL on May 9th, 2014, while Stephen Henson of the OpenSSL core team has developed the fix.

CVE-2014-0195 Vulnerability – DTLS invalid fragment vulnerability

Differently from the previous flaw, the attacker sends invalid DTLS fragments to an OpenSSL DTLS client or server to cause a buffer overrun attack and run arbitrary code on the target.

Only applications using OpenSSL as a DTLS client or server affected.

  • OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za
  • OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m.
  • OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h.

The vulnerability was discovered by Jüri Aedla, who reported it on April 23th 2014 via HP ZDI, and it was fixed by Stephen Henson of the OpenSSL core team.

CVE-2014-0198 Vulnerability – SSL_MODE_RELEASE_BUFFERS NULL pointer dereference

The attacker exploiting a flaw in the do_ssl3_write function can cause a Denial of Service via a NULL pointer dereference.

This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default setting.

  • OpenSSL 1.0.0 users should upgrade to 1.0.0m.
  • OpenSSL 1.0.1 users should upgrade to 1.0.1h.

The fix was developed by Matt Caswell of the OpenSSL development team.

CVE-2010-5298 Vulnerability – SSL_MODE_RELEASE_BUFFERS session injection or denial of service

The flaw could be exploited by a remote attackers to inject data across sessions or cause a Denial of Service. It is based on a race condition in the ssl3_read_bytes function. The vulnerability only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled. Also, in this case, this is not the default setting and it is a not common choice.

  • OpenSSL 1.0.0 users should upgrade to 1.0.0m.
  • OpenSSL 1.0.1 users should upgrade to 1.0.1h.

This issue was reported in public.

CVE-2014-3470 Vulnerability – Anonymous ECDH denial of service

The advisory issued by the OpenSSL Foundation stated that TLS clients with anonymous ECDH (Elliptic Curve Diffie Hellman) ciphersuites are vulnerable to a Denial of Service attack.

  • OpenSSL 0.9.8 users should upgrade to 0.9.8za.
  • OpenSSL 1.0.0 users should upgrade to 1.0.0m.
  • OpenSSL 1.0.1 users should upgrade to 1.0.1h.

The bug was reported by Felix Gröbert and Ivan Fratrić at Google

on May 28th 2014, while the fix was developed by Stephen Henson of the OpenSSL core team.

Not only OpenSSL – The GnuTLS implementation

GnuTLS is a free software implementation of SSL/TLS/DTLS protocols. It offers a set of application programming interface (API) to enable secure communication over their network transport layer.

Recently it has been discovered that the widely used cryptographic library is vulnerable to a buffer overflow flaw that could be exploited by attackers to crash TLS clients or potentially execute malicious code.

The bug in GnuTLS, coded as CVE-2014-3466, was discovered by Joonas Kuorilehto of the security firm Codenomicon, the same company who discovered the Heartbleed vulnerability in the OpenSSL library.

“Buffer overflow in the read_server_hello function in lib/gnutls_handshake.c in GnuTLS before 3.1.25, 3.2.x before 3.2.15, and 3.3.x before 3.3.4 allows remote servers to cause a denial of service (memory corruption) or possibly execute arbitrary code via a long session id in a ServerHello message,” is the description provided by Mitre in the CVE-ID.

The researchers discovered that the GnuTLS Vulnerability affects the way GnuTLS manages the session ID from the server response during a TLS handshake. In particular, the implementation doesn’t correctly parse the parameter, allowing it to send the session ID value in the ServerHello message of arbitrary length.

Figure – Flawed Implementation of GnuTLS

A malicious server could send an excessively long value to the target client system in order to exploit the buffer overflow vulnerability. The server could send a specifically crafted malicious payload to clients as they establish encrypted HTTPS connections. In the attack scenario, the exploitation of the GnuTLS Remote Code Execution flaw is possible only for clients that are connecting to the malicious server.

The readers that are searching for detailed analysis of the GnuTLS vulnerabilities could give a look to the information published on the Radare blog.

The GnuTLS project has already issued updated version 3.1.25, 3.2.15 and 3.3.3 to fix the flaw. Also Red Hat has issued a patch for this GnuTLS vulnerability. Below is the explanation provided on their website:

“A flaw was found in the way GnuTLS parsed session ids from Server Hello packets of the TLS/SSL handshake … A malicious server could use this flaw to send an excessively long session id value and trigger a buffer overflow in a connecting TLS/SSL client using GnuTLS, causing it to crash or, possibly, execute arbitrary code,” states Red Hat.

“The flaw is in read_server_hello() / _gnutls_read_server_hello(), where session_id_len is checked to not exceed the incoming packet size, but not checked to ensure it does not exceed the maximum session id length.”

The lesson learned is … whatever enciphering mechanism you are using, update your system as soon as possible, before hackers or intelligence agencies could exploit the mentioned vulnerabilities.