Heartbleed the bug that makes the heartbeat extension bleed

By on


A team of security engineers at Codenomicon and Google Security announced a few days ago that they have found a bug in the OpenSSL, an open-source implementation of the SSL and TLS protocols that provides communication security and privacy over the Internet for applications.

Codenomicon team said, ?The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet.?

With this, anyone on the Internet can read the memory of the systems protected by the vulnerable versions of the OpenSSL software, Codenomicon said. ?This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users, and to impersonate services and users,? the team added.

To make things clear, the team made a test by attacking their own services from an attacker’s perspective. They said, ?We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials, we were able to steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.?

The bug that is in the OpenSSL’s implementation of the TLS/DTLS heartbeat extension will leak memory contents from the server to the client and from the client to the server once exploited, the team explained.

?Encryption is used to protect secrets that may harm your privacy or security if they leak. In order to coordinate recovery from this bug, we have classified the compromised secrets into four categories: 1) primary key material, 2) secondary key material and 3) protected content and 4) collateral,? Codenomicon said.

The team discussed on their official website the different categories as follows.

  • Primary key material and how to recover 

    These are the crown jewels, the encryption keys themselves. Leaked secret keys allow the attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will. Any protection given by the encryption and the signatures in the X.509 certificates can be bypassed. Recovery from this leak requires patching the vulnerability, revocation of the compromised keys and reissuing and redistributing new keys. Even doing all this will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption. All this has to be done by the owners of the services.

  • Secondary key material and how to recover 

    These are for example the user credentials (user names and passwords) used in the vulnerable services. Recovery from these leaks requires owners of the service to first ?restore trust to the service according to steps described above. After this, users can start changing their passwords and possible encryption keys according to the instructions from the owners of the services that have been compromised. All session keys and session cookies should be invalided and considered compromised.

  • Protected content and how to recover 

    This is the actual content handled by the vulnerable services. It may be personal or financial details, private communication such as emails or instant messages, documents or anything seen as worth protecting by encryption. Only owners of the services will be able to estimate the likelihood what has been leaked and they should notify their users accordingly. Most important thing is to restore trust to the primary and secondary key material as described above. Only this enables the safe use of the compromised services in the future.

  • Leaked collateral and how to recover 

    Leaked collateral are other details that have been exposed to the attacker in the leaked memory content. These may contain technical details such as memory addresses and security measures such as canaries used to protect against overflow attacks. These have only contemporary value and will lose their value to the attacker when OpenSSL has been upgraded to a fixed version.

?You are likely to be affected either directly or indirectly,? the team said. ?OpenSSL is the most popular open source cryptographic library and TLS (transport layer security) implementation used to encrypt traffic on the Internet. Your popular social site, your company’s site, commerce site, hobby site, site you install software from or even sites run by your government might be using vulnerable OpenSSL.?

The team said that the only way to protect yourself is ?to upgrade to a fixed version of OpenSSL or to recompile OpenSSL with the handshake removed from the code? since it cannot be disabled during TLS handshake. The engineers added that vulnerable heartbeat extension code is activated regardless of the results of the handshake phase negotiations.

The Codenomicon team who found the heartbleed bug while improving the SafeGuard feature in Codenomicon’s Defensics security testing tools reported this bug to the NCSC-FI for vulnerability coordination and reporting to OpenSSL team.

Moreover, here?s the statement of the OpenSSL project as posted on the official website of the Heartbleed:

OpenSSL Security Advisory [07 Apr 2014]

TLS heartbeat read overrun (CVE-2014-0160)

A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server.

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected, including 1.0.1f and 1.0.2-beta1.

Thanks for Neel Mehta of Google Security for discovering this bug and to Adam Langley <> and Bodo Moeller <> for preparing the fix.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

1.0.2 will be fixed in 1.0.2-beta2.

(Photo courtesy of

About the author

To Top