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:
Vendor Software Patched Release Oracle MySQL Server 5.5.525.6.33
5.7.15 Percona Percona Server
Percona XtraDB Cluster 5.5.51-38.1
5.6.32-78.0
5.7.14-7 MariaDB MariaDB Server
MariaDB Galera Cluster 10.1.17
10.0.27
5.5.51 Codership MySQL Galera Cluster 5.5.52
5.6.33
If you are using ClusterControl to manage your MySQL/MariaDB databases, we advise you to do the following as soon as possible:
Upgrade MySQL or MariaDB server for ClusterControl. Upgrade ClusterControl to the latest version (recommended for #3). Upgrade your MySQL servers manually or using ClusterControl. Upgrade MySQL/MariaDB Server on ClusterControl serverClusterControl 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 allTo upgrade, simply:
$ sudo apt-get update $ sudo apt-get install mysql-server $ sudo service mysql restart #sudo systemctl restart mysqlFor 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 updatesFor the above reason, on RHEL/CentOS, we can apply the patches manually. The below recommendations are taken from Percona blog :
Patch the mysqld_safe and related filesCompare 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
Database user permissionsOne 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'); Configuration files permissionsThe 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 *.cnfVerify 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; doneThis 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/*.cnfOnce 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 versionClusterControl 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 serverFor 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 mysqlEnsure 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 oursupport portal if you need further assistance on applying the patches.
