Over the last few days, the Percona team has spent a lot of time evaluating the impact of the Heartbleed bug (CVE-2014-0160) for our customers and for the users of our software. We published a formal disclosure a few days ago. However, I thought a quick summary and some additional information would be good to provide for our MySQL Performance Blog readers.
First, I want to point out that “Heartbleed” is an issue in a commonly used third-party library which typically comes with your operating system, so there is a lot of software which is impacted. An openly exposed service, which is typically a website or some form of API, can potentially cause the biggest impact for anyone. Even though we talk a lot about MySQL Server (and its variants), it will not be the primary concern for organizations following best practices and not exposing their MySQL server to the open Internet.
Second, if you take care of patching your operating system, this will take care of Percona Server, MariaDB or MySQL Server (see note below) as well as other software which uses the OpenSSL library as long as it is linked dynamically. It is highly recommended to dynamically link OpenSSL exactly to take care of such security issues with a single library update and not wait for separate security updates for multiple software packages. Note that updating the library is not enough – you need to restart the service in order for the new library to be loaded. In most cases, I recommend a full system restart as the simplest way to guaranty that all processes using the library have been restarted.
Third, it is worth noting that not all MySQL variants have been impacted and not in all cases. Obviously, your MySQL Server is not impacted if you’re running an operating system which is not vulnerable. You will also not be vulnerable if the MySQL Server or variant you’re using uses yaSSL instead of OpenSSL. In addition, in many cases SSL support is disabled on the server side by default, which might not be the best thing from a security standpoint but can save us from this bug. Finally, in many configurations the SSL/TLS connection setup will take place after initial handshake which does not allow this vulnerability in all cases. I do not have hard numbers but I would guess no more than 10-20% of MySQL (and variants) installations would be vulnerable, even before you look at when they are exposed to the Internet.
To find out whenever MySQL is dynamically compiled with OpenSSL or yaSSL you can use this command:
1 2 | [root@localhost vagrant]# ldd /usr/sbin/mysqld | grep ssl libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007fb7f4cbc000 |
It will show “libssl” for server linked with OpenSSL dynamically and it will show no matches for server compiled with yaSSL
It is worth noting as Lenz Grimmer pointed out in a blog post comment that Heartbleed impacts not only vulnerable servers but vulnerable clients can be at risk as well if they connect to a compromised server which implements code specially targeting the clients. This means you want to make sure to update your client machines as well, especially if you’re connecting to a non-trusted MySQL Server.
But enough on Percona Software. There is an impact to Percona web systems as well. The majority of our systems have not been impacted directly because they were running an OpenSSL version which did not have the Heartbleed vulnerability. However, because of how our systems are integrated, there was a small probability that some customer accounts could be exposed through impacted services: https://rdba.percona.com and PCT. We promptly patched these services last week, regenerated keys, and reset passwords for all accounts which had even a small chance of being impacted.
We believe our teams have acted quickly and appropriately to secure our systems and minimize the chance of information leaks. We will continue to monitor the situation closely and update you via our advisory document if there is any new information needing your attention.
my client’s db got affected, fortunately we patched it next day
Could you please explain more on “Finally, in many configurations the SSL/TLS connection setup will take place after initial handshake which does not allow this vulnerability in all cases.” Thank you!
LSS,
In default configurations MySQL will not allow for the negotiation of the SSL/TLS connection until the authentication handshake has completed; meaning to be Heartbleed vulnerable (dumping memory contents) an attacker would first need valid credentials; and if correctly configured grants are in place, access to a host for which the username and password combination exists; at which point they can access any data the user has been granted too anyway thus heartbleed just adds the potential for “additional information” to be gleaned.