I’ll also list which MySQL versions include the vulnerability fixes.
To summarize, the methods used to gain root privileges require multiple conditions:
- A remote (or even local) MySQL user that has FILE permissions (or SUPER, which encompasses all of them).
- The MySQL user is allowed to create new configuration files in it’s datadir which will be loaded upon restart of MySQL as well as modify any configuration files which have write permissions to the MySQL daemon user.
- Several techniques alter the MySQL configuration to include loading a malicious shared library.
The techniques currently described require FILE or SUPER privileges, but also include the currently undisclosed CVE-2016-6663 (which demonstrates how to alter the configuration without FILE privileges).
- Have that malicious shared library loaded when MySQL restarts, which includes the code that allows privilege escalation.
MySQL seems to have already released versions that include the security fixes.
This is coming from the release notes in MySQL 5.6.33:
- For mysqld_safe, the argument to
--malloc-libnow must be one of the directories
/usr/lib/x86_64-linux-gnu. In addition, the
--mysqld-versionoptions can be used only on the command line and not in an option file. (Bug #24464380)
- It was possible to write log files ending with
.cnfthat later could be parsed as option files. The general query log and slow query log can no longer be written to a file ending with
.cnf. (Bug #24388753)
- Privilege escalation was possible by exploiting the way
REPAIR TABLEused temporary files. (Bug #24388746)
You aren’t affected if you use version 5.5.52, 5.6.33 or 5.7.15.
The way Percona increased security was by limiting which libraries are allowed to be loaded with LD_PRELOAD (including --malloc-lib), and limiting them to /usr/lib/, /usr/lib64 and the MySQL installation base directory.
This means only locations that are accessible by root users can load shared libraries.
The following Percona Server versions have this fix:
We are working on releasing new Percona XtraDB Cluster versions as well.
Future Percona Server releases will include all fixes from MySQL.
I have an older MySQL Version, what to do now?
It is possible to change the database configuration so that it isn’t affected anymore (without changing your MySQL versions and restarting your database). There are several options, each of them focusing on one of the conditions required for the vulnerability to work.
Patch mysqld_safe Manually
Just before publishing this, a blogpost came out with another alternative on how to patch your server: https://www.psce.com/blog/2016/09/12/how-to-quickly-patch-mysql-server-against-cve-2016-6662/.
Database user permissions
One way to avoid the vulnerability is making sure no remote user has SUPER or FILE privileges.
However, CVE-2016-6663 mentions there is a way to do this without any FILE privileges (likely related to the REPAIR TABLE issue mentioned in MySQL release notes).
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:
- MySQL reads configuration files from different paths, including from your
- Create an (empty) my.cnf and .my.cnf in the datadir (usually /var/lib/mysql) and make root the owner/group with 0644 permissions.
- Other Locations to look into: /etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf ( mysqld --help --verbose shows you where mysqld will look)
- This also includes !includedir paths defined in your current configurations — make sure they are not writeable by the mysql user as well
- No config files should be writeable by the mysql user (change ownership and permissions)