MySQL Database Security Upgrade Instructions for Zero-day Exploit

You must have heard about the CVE-2016-6662, the recent zero-day exploit exposed in most of MySQL and its variants. The vulnerability flaw can be exploited by a remote attacker to inject malicious settings into your my.cnf,. you can read about the details here.

At the moment, all supported MySQL vendors by ClusterControl (Oracle, Codership, Percona, MariaDB) have been patched with a bug fix and released in their respective package repository:

If you are using ClusterControl to manage your MySQL/MariaDB databases, we advise you to do the following as soon as possible:

1. Upgrade MySQL or MariaDB server for ClusterControl.
2. Upgrade ClusterControl to the latest version (recommended for #3).
3. Upgrade your MySQL servers manually or using ClusterControl.

Upgrade MySQL/MariaDB Server on ClusterControl Server

ClusterControl stores monitoring data in a MySQL/MariaDB server. The ClusterControl installer script (install-cc) relies on the respective OS’s repository to install MySQL server.

On Debian 8 and Ubuntu 14.04, the latest version of mysql-server package is patched:

ubuntu@ubuntu-trusty:~$ sudo apt list mysql-server
mysql-server/trusty-updates,trusty-security 5.5.52-0ubuntu0.14.04.1 all

To upgrade, simply:

$ sudo apt-get update
$ sudo apt-get install mysql-server
$ sudo service mysql restart #sudo systemctl restart mysql

For RHEL/CentOS 6, taken from Redhat Customer Portal, the MySQL 5.1 packages in Red Hat Enterprise Linux 6 do not implement support for library preloading, therefore preventing the remote attack vector used by the published exploit.

At the moment of writing, there is no patched MariaDB release available from RHEL/CentOS 7 repository:

[root@centos7 ]$ yum list | grep -i mariadb-server
mariadb-server.x86_64                   1:5.5.44-2.el7.centos          @base
mariadb-server.x86_64                   1:5.5.50-1.el7_2               updates

For the above reason, on RHEL/CentOS, we can apply the patches manually. The below recommendations are taken from Percona blog:

1. Patch the mysqld_safe and related files

   Compare and patch mysqld_safe, /etc/init.d/mysql and related files according to the diff shown in the following vendor’s Github repository:

   MySQL: https://github.com/mysql/mysql-server/commit/f75735e36e6569b9dae3b0605b1d5915a519260e#diff-144aa2f11374843c969d96b7b84247eaR348

   Percona: https://github.com/percona/percona-server/commit/c14be53e029442f576cced1fb8ff96b58e89f2e0#diff-144aa2f11374843c969d96b7b84247eaR261

   MariaDB: https://github.com/MariaDB/server/commit/684a165f28b3718160a3e4c5ebd18a465d85e97c

2. Database User Permissions

   One way to avoid the vulnerability is making sure no remote user has SUPER or FILE privileges. Verify if there is any user holding unnecessarily these two privileges. You can get a list of remote users that has these privileges by using the following query:

   mysql> SELECT user, host FROM mysql.user WHERE Super_priv='Y' AND File_priv='Y' AND host NOT IN ('localhost','127.0.0.1', '::1');

3. Configuration Files Permissions

   The vulnerability needs to be able to write to some MySQL configuration files. Prevent that and you are secure. Make sure you configure permissions for various config files as follows:

   Create an (empty) my.cnf and .my.cnf in the datadir (usually /var/lib/mysql) and make root the owner/group with 0644 permissions:

   $ touch /var/lib/mysql/my.cnf
   $ touch /var/lib/mysql/.my.cnf
   $ chmod 644 my.cnf .my.cnf
   $ chown root:root *.cnf

   Verify other MySQL configuration files as well in other locations:

   $ for i in "/etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf"; do chown root:root $i; chmod 644 $i; done

   This also includes “!includedir” paths defined in your current configurations – make sure they are not writeable by the mysql user as well. Consider “!includedir = /etc/my.cnf.d” is defined in my.cnf:

   $ chmod 644 /etc/my.cnf.d/*.cnf
   $ chown root:root /etc/my.cnf.d/*.cnf

   Once the RHEL/CentOS releases the patched mysql packages in their respective repository, you can then perform the package upgrade using the yum commands.

Upgrade ClusterControl to the Latest Version

ClusterControl should be updated to the latest version to ensure the upgrade steps are updated and relevant to the latest release.

The latest stable release for ClusterControl now is 1.3.2 (build 1467). Take note that if you are upgrading from 1.2.12 and below, you should perform some extra steps to re-configure /etc/cmon.cnf to use minimal configuration options. This part is further explained in the ClusterControl upgrade instructions available at our documentation page.

Upgrade the Monitored DB Server

For Galera Cluster, ClusterControl supports rolling patch upgrade (between minor versions e.g, 5.6.12 to 5.6.30) directly from the UI. To do this, go to ClusterControl -> Manage -> Upgrades -> Upgrade and it will start the rolling upgrade, one node at a time.

You are able to monitor the job progress under Logs -> Jobs:

Alternatively, you can perform the upgrade manually by following the upgrade instructions from the respective database vendor. Minor upgrade does not require you to uninstall the existing packages so it should be a pretty straightforward upgrade. For example, if you are using Percona XtraDB Cluster 5.6 on CentOS 7, you can simply perform the following on one DB node at a time:

$ yum clean all
$ yum install Percona-XtraDB-Cluster-56
$ systemctl restart mysql

Ensure the node re-joins the cluster and reaches the Primary state (monitor the wsrep_cluster_status and wsrep_cluster_size status) before proceeding to the next node.

That’s it. For Severalnines subscription customers, you are welcome to contact us via our support portal if you need further assistance on applying the patches.