By now most people have at least heard of the Heartbleed vulnerability within OpenSSL.  A number of McAfee products, including certain versions of the McAfee Email Gateway software, have been found to be vulnerable (see SB10071 for details). I’d like to attempt to help customers understand what this bug is, how it works, and what administrators should do to mitigate the issue.


The Heartbleed vulnerability is a significant and exploitable vulnerability in the wild.  Servers secured with certain versions of OpenSSL,  the dominant SSL engine on the Internet, may be vulnerable to this issue.  MEG, like many other servers, uses OpenSSL for secure communication to the UI as well as for Transport Layer Security (TLS) for email.  But what is Heartbleed?  In a nutshell, Heartbleed is caused by a bug in the code of the SSL libraries which handles TLS Heartbeat packets.  The Heartbeat feature is the mechanism which keeps a TLS session open while one device awaits activity from the other.  One device can send a heartbeat request to the other device on the TLS connection, to which the other device responds with a heartbeat response.


Where the bug comes in is in the details of the heartbeat packet.  For those who wish to research the issue in further detail, please see the link to the RFC for the heartbeat packet in the links section below.  I’ll also say that I think one of the simplest explanations for the exploit and how it works has been drawn by Randall Munroe and posted to his XKCD Cartoon archive.  This cartoon discusses the issue quite well, and better than I could explain it.  To summarize, the heartbeat packet contains a size value, a payload, and a request for a heartbeat response.  The heartbeat response sends a response containing size bytes starting with the payload.  The problem is, while the size value would intuitively seem to be something that should equal the length of the payload, the bug is that the size need not equal the length of the payload.  Thus, the attacker can send a heartbeat request with a very short payload, but say it's very long, and get a heartbeat response back with a very long payload back.  Where does the data in the long payload it gets back come from?  The memory of the targeted device.  Thus, potentially anything in the memory of the targeted device could be read back out to the attacker.


By necessity, the private keys for the targeted server *MUST* be in memory, due to the way TLS works.  The result is that it is entirely within the realm of possibility that the device's private key is in a section of memory that can end up getting caught up in the returned heartbeat data.  Because of the way TLS works, anyone who has the device's private key can pretend to be the device. 


So how do we fix the problems caused by Heartbleed?  There are three steps we need to take to completely fix this issue. 


First, it is necessary to fix the bug in the OpenSSL software.  For MEG 7.5.2 and 7.6.1, this issue was addressed in hotfixes 960401 (7.5.2) and 960405 (7.6.1), released April 11th.  Customers should get onto MEG 7.5.2 or 7.6.1 and install these hotfixes before proceeding.


Next, customers should get new private keys and certificates.  Since it's impossible to know whether or not an attacker has read out your private keys, and thus has the ability to impersonate your appliance, it is necessary to replace the private key.  Because of the way that public-key cryptography in general (of which SSL is an instance) works, if the private key changes, so must the public key.  A certificate is merely a public key which has been signed by a certificate authority.  See KB60557 for more information on how to generate a new private key and CSR. 


Finally, customers should revoke their earlier private keys.  Because of the fact that the private keys cannot be verified to be in the hands of the original owner, and thus the certificates could be misappropriated, customers should contact their CA to have any old certificates which were on the box revoked.  This marks the certificate as invalid and anyone receiving the certificate would refuse to communicate with that host.  This is necessary for ensuring the integrity of your appliances and communications.


While steps two and three are not strictly necessary, due to the fact that we cannot be sure if the keys were ever read out of the appliance it is considered a best practice for customers to replace the certificates and keys and revoke the old ones.  This precludes an attacker who did manage to read out the private keys from being able to continue to use them.



Relevant Links:


Heartbeat RFC:


McAfee Security Bulletin:


NIST CVE for Heartbleed:


XKCD Cartoon: