Heartbleed (CVE-2014-0160): An overview of the problem and the resources needed to fix it

After only a few days, the Internet is still buzzing with news surrounding CVE-2014-0160, better known as the Heartbleed vulnerability. CSO has compiled the following information in order to help administrators and security teams understand the issue, determine their risks, and if needed, fix the problem.


The Heartbleed bug was fully disclosed to the Internet on April 7, 2014, but the root cause of the problem was introduced to the OpenSSL platform two years-ago.

The name for this bug is a play on words. The media and some vendors have inaccurately reported the issue as Malware, which is a description far removed from the truth. Likewise, other inaccurate reports have said that the issue is a problem within the SSL / TLS protocols. Both explanations are false.

The Heartbleed bug exists because of a flaw in the OpenSSL implementation of the TLS/DTLS heartbeat functionality. So this is a problem with server software, not a problem with certificates. The vulnerability itself can be classified as a critical information disclosure issue.


In their advisory, the US-CERT outlines the issue perfectly.

OpenSSL versions 1.0.1 through 1.0.1f contain a flaw in its implementation of the TLS/DTLS heartbeat functionality (RFC6520). This flaw allows an attacker to retrieve private memory of an application that uses the vulnerable OpenSSL libssl library in chunks of up to 64k at a time. Note that an attacker can repeatedly leverage the vulnerability to increase the chances that a leaked chunk contains the intended secrets.

If targeted by an attacker, the flaw will yield some, if not all of the following:

  • SSL private keys, enabling the decryption of traffic if it's intercepted; however experts have said that an attacker successfully compromising private keys is unlikely.

  • Usernames and passwords that are submitted to applications and services running on the server. This is the most likely attack vector, but there have been no security incidents linked to it, at least not yet.

  • Session tokens are also exposed by this flaw, as are cookie values.

Once the vulnerability became public knowledge, many researchers and vendors have worked to examine the total attack surface.

As such, there have been reports that this vulnerability can be used to amplify traffic and trigger a DDoS, and expose application configuration files, including the connection strings were database usernames and passwords are clearly visible.

Scale and Scope (what's vulnerable):

The researchers who discovered the vulnerability have explained the most important aspects of the vulnerability as it pertains to scope:

Most notable software using OpenSSL are the open source web servers like Apache and nginx. The combined market share of just those two out of the active sites on the Internet was over 66% according to Netcraft's April 2014 Web Server Survey.

Furthermore OpenSSL is used to protect for example email servers (SMTP, POP and IMAP protocols), chat servers (XMPP protocol), virtual private networks (SSL VPNs), network appliances and wide variety of client side software. Fortunately many large consumer sites are saved by their conservative choice of SSL/TLS termination equipment and software.

Ironically smaller and more progressive services or those who have upgraded to latest and best encryption will be affected most. Furthermore OpenSSL is very popular in client software and somewhat popular in networked appliances which have most inertia in getting updates.

The following versions of OpenSSL are vulnerable to this flaw:

  • OpenSSL v. 1.0.1 1.0.1f

The following versions of OpenSSL are NOT vulnerable to this flaw:

  • OpenSSL v. 1.0.1g (Current release)
  • OpenSSL v. 1.0.0x
  • OpenSSL v. 0.9.8x

The following Linux distributions were shipped with vulnerable versions of OpenSSL:

  • Debian Wheezy (stable)
  • Ubuntu 12.04.4 LTS
  • CentOS 6.5
  • Fedora 18
  • OpenBSD 5.3
  • FreeBSD 10.0
  • NetBSD 5.0.2
  • OpenSUSE 12.2

The version of OpenSSL can be obtained by using the openssl version -a command. Versions of OpenSSL 1.0.1x that were built before April 7, 2014 are vulnerable.

As explained by the researchers who discovered the flaw:

The vulnerable versions have been out there for over two years now and they have been rapidly adopted by modern operating systems. A major contributing factor has been that TLS versions 1.1 and 1.2 came available with the first vulnerable OpenSSL version (1.0.1) and security community has been pushing the TLS 1.2 due to earlier attacks against TLS (such as the BEAST).

Testing for vulnerability:

In order to determine vulnerability, several services have been deployed that enable organizations to check the status of their servers. The following two services are the most recommended.



Fixing the problem:

Fixing the problem created by Heartbleed is a multi-step process.

1. Update OpenSSL

For Ubuntu and Debian systems, OpenSSL should be updated by issuing the apt-get update and apt-get install -y libssl1.0.0 openssl commands.

After that, issue lsof -n | grep ssl | grep DEL and restart all listed services.


Debian installs can use apt-get update followed by apt-get upgrade.


For CentOS use yum clean all && yum update "openssl*".

Issue lsof -n | grep ssl | grep DEL and restart all listed services.


Fedora 18 is no longer supported. The following applies to Fedora 19 and 20.

For Fedora 19 x86_64:

yum -y install koji

koji download-build --arch=x86_64 openssl-1.0.1e-37.fc19.1

yum localinstall openssl-1.0.1e-37.fc19.1.x86_64.rpm


Fedora 20 x86_64:

yum -y install koji

koji download-build --arch=x86_64 openssl-1.0.1e-37.fc20.1

yum localinstall openssl-1.0.1e-37.fc20.1.x86_64.rpm

Substitute i686 for 32-bit systems, or armv7hl for ARM systems (Fedora 20 only).


For OpenBSD, see this document:



For FreeBSD, see these documents:





For NetBSD, see this document:


If updating OpenSSL isn't an option for some reason, it's possible to work around the vulnerability by reverting to a non-vulnerable version of OpenSSL, or recompile OpenSSL with the -DOPENSSL_NO_HEARTBEATS flag.

2. Revoke and Replace

Once the server has been patched, all of the private keys used by it need to be regenerated. After this is done, SSL certificates need to be revoked and new ones issued using the newly regenerated keys. Be sure to restart the server in order to assure that any live sessions are terminated.

After that, all passwords - for all accounts - should be changed. If anything, this is a good idea simply out of an abundance of caution. In a technical advisory on the issue, Accuvant recommended the following for passwords:

Change passwords for all accounts this includes the following:

  • Single sign-on platforms that may have interacted with the host
  • Appliance web interface logins that may use OpenSSL/Apache
  • Active directory accounts that may have been used for backend authentication

Additional Resources:

A set of SNORT rules have been released related to this vulnerability. Rapid7 has released guidance on detecting vulnerability via Nexpose, and Metasploit has released a module for Heartbleed.

Vendor Responses

Juniper Networks





F5 Networks


Check Point



Blue Coat




Dell (Sonicwall)



This article will be updated as needed. Feel free to use the comment section below to share any additional information.

Join the CSO newsletter!

Error: Please check your email address.

Tags VulnerabilitiesunixLinuxOpenSSLvulnerabilitysoftwareWeb serversapacheoperating systemsExploits / vulnerabilitiessecurity advicesecurity

More about ApacheBlue Coat SystemsCERT AustraliaCheck Point Software TechnologiesCiscoCitrix Systems Asia PacificCSODebianDellF5F5 NetworksFedoraFortinetGoogleIBM AustraliaJuniperJuniperLinuxMozillaNetcraftNovellOpenBSDRapid7SophosUbuntuVMware AustraliaWatchguardWebsense

Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Stories by Steve Ragan

Latest Videos

  • 150x50

    CSO Webinar: The Human Factor - Your people are your biggest security weakness

    ​Speakers: David Lacey, Researcher and former CISO Royal Mail David Turner - Global Risk Management Expert Mark Guntrip - Group Manager, Email Protection, Proofpoint

    Play Video

  • 150x50

    CSO Webinar: Current ransomware defences are failing – but machine learning can drive a more proactive solution

    Speakers • Ty Miller, Director, Threat Intelligence • Mark Gregory, Leader, Network Engineering Research Group, RMIT • Jeff Lanza, Retired FBI Agent (USA) • Andy Solterbeck, VP Asia Pacific, Cylance • David Braue, CSO MC/Moderator What to expect: ​Hear from industry experts on the local and global ransomware threat landscape. Explore a new approach to dealing with ransomware using machine-learning techniques and by thinking about the problem in a fundamentally different way. Apply techniques for gathering insight into ransomware behaviour and find out what elements must go into a truly effective ransomware defence. Get a first-hand look at how ransomware actually works in practice, and how machine-learning techniques can pick up on its activities long before your employees do.

    Play Video

  • 150x50

    CSO Webinar: Get real about metadata to avoid a false sense of security

    Speakers: • Anthony Caruana – CSO MC and moderator • Ian Farquhar, Worldwide Virtual Security Team Lead, Gigamon • John Lindsay, Former CTO, iiNet • Skeeve Stevens, Futurist, Future Sumo • David Vaile - Vice chair of APF, Co-Convenor of the Cyberspace Law And Policy Community, UNSW Law Faculty This webinar covers: - A 101 on metadata - what it is and how to use it - Insight into a typical attack, what happens and what we would find when looking into the metadata - How to collect metadata, use this to detect attacks and get greater insight into how you can use this to protect your organisation - Learn how much raw data and metadata to retain and how long for - Get a reality check on how you're using your metadata and if this is enough to secure your organisation

    Play Video

  • 150x50

    CSO Webinar: How banking trojans work and how you can stop them

    CSO Webinar: How banking trojans work and how you can stop them Featuring: • John Baird, Director of Global Technology Production, Deutsche Bank • Samantha Macleod, GM Cyber Security, ME Bank • Sherrod DeGrippo, Director of Emerging Threats, Proofpoint (USA)

    Play Video

  • 150x50

    IDG Live Webinar:The right collaboration strategy will help your business take flight

    Speakers - Mike Harris, Engineering Services Manager, Jetstar - Christopher Johnson, IT Director APAC, 20th Century Fox - Brent Maxwell, Director of Information Systems, THE ICONIC - IDG MC/Moderator Anthony Caruana

    Play Video

More videos

Blog Posts