Jean-Jerome SchmidtHeartbleed OpenSSL Bug: Impact on ClusterControl Users & Recommendations on How to Protect your Systems (10.4.2014, 09:38 UTC)
April 10, 2014
By Severalnines

 

In the wake of recent concerns and debates raised around the Heartbleed bug, we wanted to update Severalnines ClusterControl users on any impact this bug might have on ClusterControl & associated databases and/or applications.

 

Background

 

If your ClusterControl's web application has been accessible on the internet, then most likely you have also been exposed to the Heartbleed OpenSSL security bug, see: http://heartbleed.com for more details. 

By default, our database deployment script enables SSL encryption for the Apache web server on the Controller host with a generated private SSL key and a self-signed certificate. SSL encryption is used between the UI and the Controller REST API if you have clusters added with HTTPS, which we do by default. The content that is encrypted (and which an attacker could potentially get access to via this bug) is primarily monitoring and ClusterControl application data.

 

Recommendations

 

Test your server for Heartbleed: https://www.ssllabs.com/ssltest

 

You should generate a new private key and certificate if you are concerned that your Controller server has been compromised and of course immediately upgrade the OpenSSL package for your distribution.

 

First create a self-signed certificate by following the instructions in this post: 

http://www.akadia.com/services/ssh_test_certificate.html

 

Then, install the new private key and certificate by updating your Apache web server configuration and restart the web server.

 

read more

Link
SkySQL TeamPercona Live 2014 Wrap-up: 4400+ DBA hours spent away from work, and we all survived.. I think... (10.4.2014, 03:35 UTC)


We brought our finest to Percona Live this year!

read more

Link
Peter ZaitsevHeartbleed: Separating FAQ From FUD (9.4.2014, 18:52 UTC)

If you’ve been following this blog (my colleague, David Busby, posted about it yesterday) or any tech news outlet in the past few days, you’ve probably seen some mention of the “Heartbleed” vulnerability in certain versions of the OpenSSL library.

So what is ‘Heartbleed’, really?

In short, Heartbleed is an information-leak issue. An attacker can exploit this bug to retrieve the contents of a server’s memory without any need for local access. According to the researchers that discovered it, this can be done without leaving any trace of compromise on the system. In other words, if you’re vulnerable, they can steal your keys and you won’t even notice that they’ve gone missing. I use the word “keys” literally here; by being able to access the contents of the impacted service’s memory, the attacker is able to retrieve, among other things, private encryption keys for SSL/TLS-based services, which means that the attacker could be able to decrypt communications, impersonate other users (see here, for example, for a session hijacking attack based on this bug), and generally gain access to data which is otherwise believed to be secure. This is a big deal. It isn’t often that bugs have their own dedicated websites and domain names, but this one does: http://www.heartbleed.com

Why is it such a big deal?

One, because it has apparently been in existence since at least 2012. Two, because SSL encryption is widespread across the Internet. And three, because there’s no way to know if your keys have been compromised. The best detection that currently exists for this are some Snort rules, but if you’re not using Snort or some other IDS, then you’re basically in the dark.

What kinds of services are impacted?

Any software that uses the SSL/TLS features of a vulnerable version of OpenSSL. This means Apache, NGINX, Percona Server, MariaDB, the commercial version of MySQL 5.6.6+, Dovecot, Postfix, SSL/TLS VPN software (OpenVPN, for example), instant-messaging clients, and many more. Also, software packages that bundle their own vulnerable version of SSL rather than relying on the system’s version, which might be patched. In other words, it’s probably easier to explain what isn’t affected.

What’s NOT impacted?

SSH does not use SSL/TLS, so you’re OK there. If you downloaded a binary installation of MySQL community from Oracle, you’re also OK, because the community builds use yaSSL, which is not known to be vulnerable to this bug. In fact, anything that’s been built against yaSSL (or some other SSL library that isn’t OpenSSL) should be fine. Obviously, any service which doesn’t use SSL/TLS is not going to be vulnerable, either, since the salient code paths aren’t going to be executed. So, for example, if you don’t use SSL for your MySQL connections, then this bug isn’t going to affect your database server, although it probably still impacts you in other ways (e.g., your web servers).

What about Amazon cloud services?

According to Amazon’s security bulletin on the issue, all vulnerable services have been patched, but they still recommend that you rotate your SSL certificates.

Do I need to upgrade Percona Server, MySQL, NGINX, Apache, or other server software?

No, not unless you built any of these and statically-linked them with a vulnerable version of OpenSSL. This is not common. 99% of affected users can fix this issue by upgrading their OpenSSL libraries and cycling their keys/certificates.

What about client-level tools, like Percona Toolkit or XtraBackup?

Again, no. The client sides of Percona Toolkit, Percona XtraBackup, and Percona Cloud Tools (PCT) are not impacted. Moreover, the PCT website has already been patched. Encrypted backups are still secure.

There are some conflicting reports out there about exactly how much information leakage this bug allows. What’s the deal?

Some of the news articles and blogs claim that with this bug, any piece of the server’s memory can be accessed. Others have stated that the disclosure is limited to memory space owned by processes using a vulnerable version of OpenSSL. As far as we are aware, and as reported in CERT’s Vulnerability Notes Database, the impact of the bug is the latter; i.e., it is NOT possible for an attacker to use this exploit t

Truncated by Planet PHP, read more at the original (another 6358 bytes)

Link
Colin CharlesBook in Korean: Real MariaDB (9.4.2014, 11:13 UTC)

Real MariaDBFor some months now, there have been some back & forth emails with Matt, one of the senior DBAs behind the popular messaging service, KakaoTalk (yes, they are powered by MariaDB). Today I got some positive information: the book published entirely in the Korean language, titled Real MariaDB is now available.

It covers MariaDB 10.0. Where appropriate, there are also notes on MySQL 5.6 (especially with regards to differences). This is Matt’s fourth MySQL-related book, and there’s a community around it as well. The foreword is written by Monty and I.

If you’re reading the Korean language, this is the manual to read. It should push MariaDB further in this market, and the content is relatively quite advanced covering a lot of optimization explanations, configuration options, etc. At 628 pages, it is much, much better than the Korean translation of the Knowledge base!

Related posts:

  1. Book: MariaDB Crash Course
  2. MariaDB 5.1.44 released
  3. MariaDB 5.1.42 released!
Link
SkySQL TeamMariaDB 10.0.10 Overview and Highlights (8.4.2014, 21:20 UTC)

MariaDB 10.0.10 was recently released, and is available for download here:

https://downloads.mariadb.org/mariadb/10.0.10/

This is the first GA ("Generally Availability", aka "recommended for production systems") release of MariaDB 10.0, and 11th overall release of MariaDB 10.0.

Since this is the initial 10.0 GA release, this is primarily a bug-fix and polishing release.

Here are the main items of note:

read more

Link
Peter ZaitsevOpenSSL heartbleed CVE-2014-0160 – Data leaks make my heart bleed (8.4.2014, 15:04 UTC)

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 heartbleed.com Redhat Bugzilla Mitre CVE filing Ubuntu Security Notice

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

 

The post OpenSSL heartbleed CVE-2014-0160 – Data leaks make my heart bleed appeared first on MySQL Performance Blog.

Link
Shlomi NoachSome anecdotes I learned at Percona Live (8.4.2014, 02:06 UTC)

While on the plane back home I wrote down all my impressions from Percona Live 2014. Have lots of TODOs and great ideas to implement. Among all my impressions, there were a few anecdotes worth noting.

  • 5.6 GTID is still unfriendly. It will require complete shutdown & reconfiguration of your entire replication topology; and some companies present hacks around this. Notable, Facebook recoded GTID related code (slave agrees to replicate with GTID even though its master still uses binlog coordinates). Booking.com have their own hack around slowly migrating their topologies. And in a great lightning talk we were shown how to patch MySQL such that the relay logs turn into a  consistent GTID-like coordinate system.
  • Galera replication has been implemented for TokuDB (only active-passive mode, not active-active). This came as a surprise to Tokutek ; apparently Codership did this within a few hours of work. The rest is up for Tokutek!
  • WebScaleSQL is a cool initiative that aims to assist in pushing commonly desired featured back upstream. It is Web Scale. It is also not a productio0n distribution and I do not expect it to be, It is not a fork that is meant for the common DBA to download and deploy.
  • Tungsten replicator has MySQL to Hadoop replication using staging tables - an auditing of changes that are group-deployed on Hadoop.
  • Still so many people unfamiliar with MySQLSandbox. It's such a basic tool, especially for testing and local installations.
  • Still misconceptions about common_schema. Yes, I do use it on production.
  • Everyone has the same problems :)
  • Replication is still queen of MySQL's featureset. We're still all about failing over, promoting, scaling via replication.
  • Linux rules. Where two MacBooks failed to connect to the projector, my Lenovo/Ubuntu Linux did the job just fine and saved the day.
Link
Peter ZaitsevOptimizing MySQL Performance: Choosing the Right Tool for the Job (7.4.2014, 21:00 UTC)

Next Wednesday, I will present a webinar about MySQL performance profiling tools that every MySQL DBA should know.

Application performance is a key aspect of ensuring a good experience for your end users. But finding and fixing performance bottlenecks is difficult in the complex systems that define today’s web applications. Having a method and knowing how to use the tools available can significantly reduce the amount of time between problems manifesting and fixes being deployed.

In the webinar, titled “Optimizing MySQL Performance: Choosing the Right Tool for the Job,” we’ll start with the basic top, iostat, and vmstat then move onto advanced tools like GDB, Oprofile, and Strace.

I’m looking forward to this webinar and invite you to join us April 16th at 10 a.m. Pacific time. You can learn more and also register here to reserve your spot. I also invite you to submit questions ahead of time by leaving them in the comments section below. Thanks for reading and see you next Wednesday!

The post Optimizing MySQL Performance: Choosing the Right Tool for the Job appeared first on MySQL Performance Blog.

Link
Venu AnugantiMongoDB Map-reduce How To Avoid Global Locks (5.4.2014, 09:25 UTC)
Two important features that drives analytics in MongoDB are: Aggregation Map-Reduce In general most of the aggregation framework does not require any global write lock, but Map-reduce needs global write[...]
Link
Peter ZaitsevFacebook’s Yoshinori Matsunobu on MySQL, WebScaleSQL & Percona Live (4.4.2014, 17:41 UTC)
Facebook's Yoshinori Matsunobu

Facebook’s Yoshinori Matsunobu

I spoke with Facebook database engineer Yoshinori Matsunobu here at Percona Live 2014 today about a range of topics, including MySQL at Facebook, the company’s recent move to WebScaleSQL, new MySQL flash storage technologies – and why attending the Percona Live MySQL Conference and Expo each year is very important to him.

Facebook engineers are hosting several sessions at this year’s conference and all have been standing room only. That’s not too surprising considering that Facebook, the undisputed king of online social networks, has 1.23 billion monthly active users collectively contributing to an ocean of data-intensive tasks – making the company one of the world’s top MySQL users. And they are sharing what they’ve learned in doing so this week.

You can read my previous post where I interviewed five Facebook MySQL experts (Steaphan Greene, Evan Elias, Shlomo Priymak, Yoshinori Matsunobu and Mark Callaghan) and below is my short video interview with Yoshi, who will lead his third and final session of the conference today at 12:50 p.m. Pacific time titled, “Global Transaction ID at Facebook.”

The post Facebook’s Yoshinori Matsunobu on MySQL, WebScaleSQL & Percona Live appeared first on MySQL Performance Blog.

Link
LinksRSS 0.92   RDF 1.
Atom Feed