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.0.1e-2+deb7u5 is reported as patched on debian,
- 1.0.1e-16.el6_5.7 is reported as patched in RedHat
- 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.
- 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 heartbleed.com Redhat Bugzilla Mitre CVE filing Ubuntu Security Notice
UPDATE 2014-04-10: This video provides a fantastic description on heartbleed
I think you mean “private keys” not “primary keys”. 🙂
Pascal,
*facepalm* indeed; can I blame the jet lag? I know I’d like to! I’ve amended the post.
Cheers
David
Shouldn’t one update to OpenSSL > 1.0.1f? I thought 1.0.1f is vulnerable?
Just my 2c,
Jan
Jan,
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.
Cheers
David
You also typo’d it as >= 1.0.1f in the second paragraph
Thomas,
Thanks corrected in place;
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
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?
Danny,
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)
Is there a way to determine if you have been compromised?
Yes – you can: http://filippo.io/Heartbleed/
Nils,
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
Cheers
David
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
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.
Cheers
David
In the meantime, this site has a lot of information on the problem: http://heartbleed.com/
Hi Nils,
yes that’s linked at the end of the article.
Cheers
David
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 😉
Sleep … what is this sleep you speak of 😉 ?
need caffeine … send coffee!
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.
Hi,
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-
openssl-devel-0.9.8e-12.el5_4.6
openssl-0.9.8e-12.el5_4.6
Santheesh,
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.
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?
Richard,
See followup blog post by Ernie http://www.mysqlperformanceblog.com/2014/04/09/heartbleed-separating-faq-from-fud/
There is a web site you can use to check if given open web server vulnerable: http://filippo.io/Heartbleed/
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.
The fix is already there in version “1.0.1e-16.el6_5.7” or higher.
“If you run
rpm -q openssland 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.”https://www.centos.org/forums/viewtopic.php?f=9&t=45814
Adel-Mawala,
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.
Cheers
David
My question is: How can I perform this Heartbleed Bug on some websites? 😀
Eli,
There’s many pop up checking sites, and POC code, however as this article notes: http://www.theregister.co.uk/2014/04/11/heartbleed_health_checking_services_may_be_illegal/ checking for heartbleed may land you on the wrong side of a 10 year jail term.
So generally not a good idea 😉
David,
Not a problem for me. :p
I just wanna win some $$ 😀
Heartbleed advisory for Percona Software users and customers
https://www.percona.com/ceo-customer-advisory-heartbleed
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?
@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.