OpenSSL heartbleed CVE-2014-0160 – Data leaks make my heart bleed

The heartbleed bug was introduced in OpenSSL 1.0.1 and is present in

  • 1.0.1
  • 1.0.1a
  • 1.0.1b
  • 1.0.1c
  • 1.0.1d
  • 1.0.1e
  • 1.0.1f

The bug is not present in 1.0.1g, nor is it present in the 1.0.0 branch nor the 0.9.8 branch of OpenSSL some sources report 1.0.2-beta is also affected by this bug at the time of writing, however it is a beta product and I would really recommend not to use beta quality releases for something as fundamentally important as OpenSSL in production.

The bug itself is within the heartbeat extension of OpenSSL (RFC6520). The bug allows an attacker to leak the memory in up to 64k chunks, this is not to say the data being leaked is limited to 64k as the attacker can continually abuse this bug to leak data, until they are satisfied with what has been recovered.

At worst the attacker can retrieve the private keys, the implications for which is that the attacker now has the keys to decrypt the encrypted data, as such the only way to be 100% certain of protection against this bug is to first update OpenSSL (>= 1.0.1g) and then revoke and regenerate new keys and certificates, expect to see a tirade of revocations and re-issuing of CA certs and the like in the coming days.

So how does this affect you as a MySQL user?

Taking Percona Server as an example, this is linked against OpenSSL, meaning if you want to use TLS for your client connections and/or your replication connections you’re going to need to have openSSL installed.

You can find your version easily via your package manager for example:

  • rpm -q openssl
  • dpkg-query -W openssl

If you’re running a vulnerable installation of OpenSSL an update will be required.

  • update OpenSSL >= 1.0.1g
  1. 1.0.1e-2+deb7u5 is reported as patched on debian,
  2. 1.0.1e-16.el6_5.7 is reported as patched in RedHat
  3. 1.0.1e-16.el6_5.4.0.1.centos is reported as being an interim patch for CentOS from the updates repository this is superseded by the RedHat package where available.
  4. 1.0.1e-37.66 changelogs note this has been patched on Amazon AMI
  • shutdown mysqld
  • regenerate keys and certs used by mysql for TLS connections (revoking the old certs if possible to do so)
  • start mysqld

You can read more about the heartbleed bug at Redhat Bugzilla Mitre CVE filing Ubuntu Security Notice

UPDATE 2014-04-10: This video provides a fantastic description on heartbleed


Share this post

Comments (32)

  • Pascal

    I think you mean “private keys” not “primary keys”. 🙂

    April 8, 2014 at 11:55 am
  • David Busby


    *facepalm* indeed; can I blame the jet lag? I know I’d like to! I’ve amended the post.



    April 8, 2014 at 12:30 pm
  • Jan Rusch

    Shouldn’t one update to OpenSSL > 1.0.1f? I thought 1.0.1f is vulnerable?

    Just my 2c,


    April 8, 2014 at 12:43 pm
  • David Busby


    Indeed I can see I typoed in the final set of bullet points (whilst I did include that f was vulnerable in the first), I’ve updated this accordingly.



    April 8, 2014 at 1:13 pm
  • Thomas Maerz

    You also typo’d it as >= 1.0.1f in the second paragraph

    April 8, 2014 at 2:24 pm
  • David Busby


    Thanks corrected in place;

    April 8, 2014 at 2:26 pm
  • Jim

    I’m sorry if i sound very ignorant right now but BBC news said and I quote, “If you need strong anonymity or privacy on the internet, you might want to stay away from the internet entirely for the next few days while things settle”, is this true, should I avoid the Internet.

    Regards, Jim

    April 8, 2014 at 3:40 pm
  • Danny Wheeler

    This kinda has me paranoid, as I first heard of it on Tumblr.

    I usually stay logged in myself, hoping it keeps troublemakers at bay, and I’m usually on regularly, so if there is trouble, I’d probably spot it quickly.

    But what are the odds of, say, something of mine being exposed?

    April 8, 2014 at 4:59 pm
  • Peter Zaitsev


    I think the main concern for most people will be their Web servers because these are facing public internet. If you’re running MySQL on local network it will not be vulnerable to external attacks and I hope you can trust your people.

    It also only will be the issue if you’re using OpenSSL to connect to MySQL which is disabled by default in many instances.

    Having said that, Web server vulnerability can cause a lot of problems too – in Web Server memory you’re likely have credentials to access MySQL database as well as results of potentially sensitive database queries. Former is the biggest issue I believe as database credentials in most cases are not enough to access MySQL Server which is also protected by firewall but data is data.

    Our Security Team is still looking in more details but it looks like there are no good trace left in MySQL when this hole is used. However if someone is dumping a lot of memory contents for analyses you’re likely to see significant traffic on network level with no corresponding MySQL queries (in case MySQL Server was attacked)

    April 8, 2014 at 5:30 pm
  • Nils

    Is there a way to determine if you have been compromised?

    April 8, 2014 at 6:42 pm
  • Dave Juntgen April 8, 2014 at 11:30 pm
  • David Busby


    As Dave J points out you can test for the vulnerability, in terms of knowing if you have been compromised as this has existed for the last 2 years, you’ll have needed to have pre existing IDS systems targeting SSL heartbeats

    In the first instance you should determine if you are vulnerable and take it from there, my colleague Ernie will be making a follow up post I highly recommend you read this as it becomes available



    April 9, 2014 at 4:10 am
  • Lenz Grimmer

    Please note that RHEL and derivatives (CentOS, Oracle Linux) published updated openssl RPMs that still identify itself as version “1.0.1e”, even though it includes a patch to fix this particular vulnerability. If in doubt, check the RPM changelog itself:

    # rpm -q –changelog openssl | head -2
    * Mo Apr 07 2014 Tomáš Mráz 1.0.1e-16.7
    – fix CVE-2014-0160 – information disclosure in TLS heartbeat extension

    April 9, 2014 at 5:56 am
  • David Busby

    Hi Lenz,

    As I noted in the post “1.0.1e-16.el6_5.7 is reported as patched in RedHat and CentOS” this links to the errata noting this also.

    Thanks for the input though.



    April 9, 2014 at 6:21 am
  • Nils

    In the meantime, this site has a lot of information on the problem:

    April 9, 2014 at 7:33 am
  • David Busby

    Hi Nils,

    yes that’s linked at the end of the article.



    April 9, 2014 at 8:07 am
  • Nils

    Oh damn, totally overlooked that last line. Good thing I don’t have that many servers to maintain these days, I might have gotten no sleep 😉

    April 9, 2014 at 8:10 am
  • David Busby

    Sleep … what is this sleep you speak of 😉 ?

    need caffeine … send coffee!

    April 9, 2014 at 8:13 am
  • Dag Wieers

    It was not explicitly mentioned in the article, but RHEL6 only introduced the vulnerable version of openssl in RHEL6.5 (released on 2013-11-21), so your RHEL systems were vulnerable since the day you updated them to RHEL6.5. If you’re running RHEL6.4 or older, you are not impacted (and you won’t be impacted when you update).

    The irony is that in this case you would have been better off security-wise if you did no update your systems too regularly (and e.g. sticked with an EUS release or RHEL5). However this incident is a bad argument for not patching your systems regularly as this is a very rare and unusual case… I never experienced anything like this one for the past 20 years. I remember the OpenSSH off-by-one incident from 2002 which was different in that it wasn’t remotely exploitable.

    April 9, 2014 at 10:16 am
  • Satheesh


    This post does clear some doubts I had. One last thing though.. the RHEL machines we deploy in our private cloud use the SSL version ‘0.9.8e’. If the the bug is in ‘1.0.1[a-f]’ is the version with ‘0.9.8e’ safe for now?

    # rpm -qa|grep openssl-

    April 9, 2014 at 1:26 pm
  • Peter Zaitsev


    Yep if you’re using older operating system with openssh 0.9.8 you’re safe. See comment above it is even more interesting with RHEL6 (CentOS6 etc) where you only get exposed if you followed the prudent practices of getting timely security updates.

    April 9, 2014 at 1:29 pm
  • Richard Green

    What can I recommend to the end-users that are pestering me today? How can we test whether a particular site has applied the patch or upgraded?
    Has someone written a plugin or extension for the browsers that will pop up a warning when a website attempts to switch to https with an unpatched ssl engine and/or certificates that pre-date the patch?

    April 9, 2014 at 2:41 pm
  • Peter Zaitsev


    See followup blog post by Ernie
    There is a web site you can use to check if given open web server vulnerable:

    April 9, 2014 at 3:29 pm
  • Richard Green

    Ah, Thank you!

    …and that web site has a link to the ‘Chromebleed’ extension for the Chrome Browser that does the checking for you in the background, and warns you with a pop-up before you enter your credentials into an unpatched website.

    April 9, 2014 at 3:44 pm
  • Abdel-Mawla Ghaireb

    The fix is already there in version “1.0.1e-16.el6_5.7” or higher.
    “If you run rpm -q openssl and it reports version 1.0.1e and less than 1.0.1e-16.el6_5.4.0.1 then you are currently vulnerable to this problem. If it reports 1.0.1e-16.el6_5.4.0.1.centos then you have the temporary version issued before Redhat issued their official fix. If you have 1.0.1e-16.el6_5.7 or higher then you have the official fixed version.”

    April 10, 2014 at 3:59 am
  • David Busby


    As I note in the end of the post 1.0.1e-16.el6_5.7 is patched this links to the redhat errata on the issue also (RHSA-2014-0376), lastly please note the forum topic to which you have linked I can see that “1.0.1e-16.el6_5.4.0.1.centos” is noted as being an interim fix whilst waiting for the RedHat packages to come “downstream” thank you for this information, I’ll update the blog post to reflect this accordingly.



    April 10, 2014 at 6:46 am
  • Eli

    My question is: How can I perform this Heartbleed Bug on some websites? 😀

    April 11, 2014 at 11:52 am
  • David Busby


    There’s many pop up checking sites, and POC code, however as this article notes: checking for heartbleed may land you on the wrong side of a 10 year jail term.

    So generally not a good idea 😉

    April 11, 2014 at 11:56 am
  • Eli


    Not a problem for me. :p

    I just wanna win some $$ 😀

    April 11, 2014 at 1:01 pm
  • Peter Zaitsev

    Heartbleed advisory for Percona Software users and customers

    April 11, 2014 at 6:06 pm
  • Keshab

    Hi David, what are the services that I need to restart after updating the OpenSSL ?and what is the difference between service reload and restart? Could you please possibly explain this to me?

    April 13, 2014 at 5:07 pm
  • Ernie Souhrada

    @Keshab –

    There is information on how to figure out which services need to be restarted in my follow-up blog post. Basically, you can run “sudo lsof | grep ssl | grep DEL” and that will show you which services are still running against the deleted library. Most likely the services that you’ll need to restart are your web server, MySQL, and your SMTP/IMAP/POP servers. Are there others? Possibly, if they are linked to a vulnerable version of OpenSSL.

    Also, the difference between a service reload and a restart depends a bit on the service, but you can think of a reload (in most cases) as a re-read of configuration files. A restart is just what it sounds like – stop the service completely and then start it up again.

    April 13, 2014 at 7:01 pm

Comments are closed.

Use Percona's Technical Forum to ask any follow-up questions on this blog topic.