Protect Your Assets
Showing results for 
Search instead for 
Do you mean 

Thoughts on the Heartbleed Bug

danielmiessler ‎04-09-2014 09:39 AM - edited ‎07-07-2015 12:36 PM


The Heartbleed bug is big. It's bigger than most thought it was when they heard about it, and now that the patching dance has begun people are finally starting to feel the weight of it.


In this short article we'll cover some basics (what the bug is, what the risks are to organizations) and we'll offers some analysis and commentary as well.


The bug


Let's talk first about what the bug is. In simple language, the bug is a flaw in certain versions of OpenSSL that allows an attacker to read areas of memory from a system running the software. This functionality is part of the SSL "heartbeat" functionality--hence the name--and it allows one to read data from the server in 64 byte chunks per query.


More information can be found here (NVD): 




Adding to the severity of the bug is the fact that multiple requests can be made in order to pull significant data from the vulnerable system. The most common question we get related to that is simply, "Ok, but what can they read out of memory?"


This breaks down to two main issues:

  1. It's possible to use this technique to read the private keys associated with a vulnerable server's certificate, thus making it possible to 1) impersonate that server, and 2) decrypt data sent to it.
  2. It's possible to use this technique to extract sensitive data that's been sent over the "secure" connection. This can include things like customers' financial data, PII, administrative credentials, etc.



The heartbleed bug is an interesting example of complexity adding insecurity. It's a simple matter of surface area--the more you have the more chance you have for bugs.


It's not without irony that the vulnerable component is security software itself. It reminds this writer of performing penetration tests for customers whereby the method of gaining system level access to the system was in fact the security agent (AV/HIPS/etc).


There are a couple of lessons to take from this:

  • Simplicity of mechanism is key. The more complexity you have the more potential you have for insecurity. Without any other knowledge, the assumption should be made that a simple system is more secure than a complex one. In this case we see that something as seemingly benign as a heartbeat function can rock the entire Internet.
  • A push for performance is often the enemy of security. It is still being discussed, but it appears that a conscious decision was made by the development team to avoid the critical bounds check at play here in the name of performance. The link between performance and insecurity is not intrinsic, as it's really just one example of a functionality decision (in this case performance) coming before security, but the flag should be raised in the mind of every security person once they hear "Ok, well, let's do what we need to do to make this thing fast."  

Recommended actions


As recommended by the OpenSSL website, there are two main ways to address the issue:

  1. Upgrade to OpenSSL 1.0.1g
  2. Recompile OpenSSL with DOPENSSL_NO_HEARTBEATS 

Additionally, here is a link that allows you to check to see if a given domain is vulnerable. One caveat on the tool, however, and on similar tools whenever you see them: Look into what they're doing before you use them. The tool below, for example, will validate the issue exists by actually pulling 64K of memory, and many similar tools do the same.


This doesn't mean you shouldn't use it (it's live on the Internet where anyone can do the same) but you should at least be aware of it.


About Fortify on Demand


Fortify on Demand is a cloud-based application security solution. We perform multiple types of security testing, including web assessments, mobile application assessments, thick client testing, SAP, etc.--and we do it using both static and dynamic techologies and techniques.


We also have the ability to tell you if you're vulnerable to the heartbleed issue, at scale, very quickly.


We're here if you need us. Feel free to reach out on Twitter @hpappsecurity or via fodsales(at) to get your questions answered.


Additional information


Here are a few links for additional reading:





As always, feel free to reach out with any questions via Twitter (@danielmiessler) or via email (


: :
Daniel Miessler is a Practice Principal with Fortify on Demand based out of San Francisco, California. His areas of expertise are web and mobile application security testing and building application security programs for the Global and Fortune 100. He can be reached at and on Twitter at @danielmiessler


About the Author


on ‎04-09-2014 12:38 PM

Are the HP Tipping Point IPS Sensors and the management platform running a vulnerble version of OpenSSL?

Stoyan Tsalev
on ‎04-10-2014 04:44 AM

What about commercial NIX-es, running OpenSSL ? I know for sure it's not common, but is totally not an exception to see HP-UX running Apache (that requires OpenSSL) or AIX server with OpenSSH (also requiring OpenSSL)

I'm 99% sure HP-UX is not affected if you're using the official distribution here  but I can't get much of reliable info for AIX and Solaris so far...


on ‎04-11-2014 10:03 AM

Are printers and their web based config pages affected? Would they use open SSL? Or say a secure release printer that uses a key fob or card to release a print job?

Nathan Grist
on ‎04-11-2014 10:54 AM

How about your thoughts or URL's on HP vulnerability assessment for all your products such as iLO and System Management Homepage, etc. ?

27 Feb - 2 March 2017
Barcelona | Fira Gran Via
Mobile World Congress 2017
Hewlett Packard Enterprise at Mobile World Congress 2017, Barcelona | Fira Gran Via Location: Hall 3, Booth 3E11
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all