Is Your Database Affected by CVE-2016-6662?

CVE-2016-6662In this blog post, I will discuss the CVE-2016-6662 vulnerability, how to tell if it affects you, and how to prevent the vulnerability from affecting you if you have an older version of MySQL.

I’ll also list which MySQL versions include the vulnerability fixes.

As we announced in a previous post, there are certain scenarios in Percona Server (and MySQL) that can allow a remote root code execution (CVE-2016-6662).

Vulnerability approach

The website contains the full, current explanation of the CVE-2016-6662 vulnerability.

To summarize, the methods used to gain root privileges require multiple conditions:

  1. A remote (or even local) MySQL user that has FILE permissions (or SUPER, which encompasses all of them).
  2. 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.
  3. 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).
  4. Have that malicious shared library loaded when MySQL restarts, which includes the code that allows privilege escalation.

Fixed versions

MySQL fixes

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-lib now must be one of the directories /usr/lib/usr/lib64/usr/lib/i386-linux-gnu, or /usr/lib/x86_64-linux-gnu. In addition, the --mysqld and --mysqld-version options 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 .ini or .cnf that 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 .ini or .cnf. (Bug #24388753)
  • Privilege escalation was possible by exploiting the way REPAIR TABLE used temporary files. (Bug #24388746)

You aren’t affected if you use version 5.5.52, 5.6.33 or 5.7.15.

Release notes: 5.5.525.6.335.7.15

Percona Server

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.


MariaDB has fixed the issue in 5.5.5110.1.17 and 10.0.27

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:

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 datadir
    • 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)

Share this post

Comments (28)

  • Paul

    Thankyou for distilling the vulnerability down to a simple checklist. Really useful summary!

    September 12, 2016 at 6:58 pm
  • Richard

    One important correction – if you change ownership of my.cnf to root, the permission needs to be 644 so that the mysql user can read the file and load the variables. This was the case with FreeBSD 10.2 and MySQL 5.6.30

    September 13, 2016 at 2:16 am
    • Kenny Gryp

      It was not necessary for me to have 0644 permissions on Centos7 with Percona Server 5.6.*, but in some cases as you mentioned it might be a problem.

      I’ve changed it from 0600 to 0644.

      September 13, 2016 at 3:50 pm
  • PLR

    Do you know if MariaDB is affected by the same vulnerability? My server can’t be accessed remotely unless they come in through my web nodes.

    September 14, 2016 at 2:13 am
    • Rasmus

      Yes, MariaDB is also affected. I wrote a blog post about it the other day, which you can find here:

      September 14, 2016 at 5:40 am
      • PLR

        I just ran an update on my Debian install and the version reported is 10.0.26 still, even though there was an update for the MariaDB client and server that ran. Has Debian pushed packages out yet after Aug 25 update?

        September 14, 2016 at 9:35 am
        • Paul

          If you have upgraded and restarted mysqld, then see what select @@VERSION says

          Some repository maintainers do not bump the stated version number when they are backporting fixes (ie redhat are notable for this)

          September 14, 2016 at 10:03 am
          • PLR

            Still says 10.0.26-MariaDB-0+deb8u1, I’m not worried though. the only way anyone can get in my server is if they hold a gun to my head since I’ve locked down all of it. Each database has their own user and root is disabled. The machine running the DB isn’t visible to the internet at all. So I’m going to leave it for now, did the upgrade, no version to go with it, so meh.

            September 14, 2016 at 10:32 am
  • Stas Kysel

    If you want to keep my.cnf only readable by MySQL (and nobody else) and not writeable by MySQL, you can always do:
    chmod 640 my.cnf
    chown root:mysql my.cnf

    September 14, 2016 at 3:16 am
    • PLR

      you login as root? ouch

      September 14, 2016 at 4:04 am
  • Michael

    From what i get its only version 5.5, 5.6 and 5.7 thats affected ?? im running 5.1.x and from what i can gather of information im not affected – or am i wrong on that assumption?

    September 14, 2016 at 5:04 am
    • Dmitry Pupking

      Hi! I’m interesting the same question. Is 5.1 branch also affected?
      I use CentOS 6.6 and in repository exists only this version of MySQL.

      September 14, 2016 at 9:21 am
      • Paul

        If you have upgraded and restarted mysqld, then see what select @@VERSION says

        Some repository maintainers do not bump the stated version number when they are backporting fixes (ie redhat are notable for this)

        September 14, 2016 at 10:02 am
        • Paul

          Sorry, ignore this. I replied to the wrong comment 🙂

          September 14, 2016 at 10:02 am
      • Bernhard

        It states, You aren’t affected if you use version 5.5.52, 5.6.33 or 5.7.15.

        So i read it like, all other versions are affected.. Anyway i did both the suggestions to be sure..

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

        2. Added the suggestions to file /usr/bin/mysqld_safe

        as discribed here.

        September 14, 2016 at 11:39 am
      • Ashraf

        According to Redhat Customer Portal, :

        “The MySQL 5.1 packages in Red Hat Enterprise Linux 6 do not implement support for library preloading, completely preventing the remote attack vector used by the published exploit.”

        September 23, 2016 at 10:21 am
    • Kenny Gryp

      5.1 seems unaffected by this as does not have the --malloc-lib configuration option and does not contain LD_PRELOAD related code: Source Code:

      September 15, 2016 at 1:50 am

    On the same line with Bernhard, It states, You aren’t affected if you use version 5.5.52, 5.6.33 or 5.7.15. But report on says those are affected versions. Do you want to say other way round?

    September 14, 2016 at 8:29 pm
    • Kenny Gryp

      The fixed versions in Percona Server and Oracle MySQL contain code changes that disallow loading shared libraries from non standard directories (allows /usr/lib, /usr/lib64…). These directories require root access and are not writeable by the mysql user so it requires another vulnerability to be able to get the shared libraries written to those paths.

      This means the vulnerability mentioned in CVE-2016-6662 is not exploitable on these versions.

      The information on must have a slight bug where it should be < instead of <=

      September 15, 2016 at 1:45 am
  • Patrick Forsberg

    If I haven’t missed something, then the patch by percona isn’t fixing the issue with non standard directories.

    It’s supposed to limit preloading libraries to /usr/lib64 and /usr/lib but as far as I can see you can use “dot dot” escaping to supply a path outside these libraries.


    September 15, 2016 at 8:21 am
    • dbpercona

      Patrick, we have reviewed the changes and you are indeed correct. The wildcard matching on /{libdir}/* will allow for parent directories to be appended to the library path spec. We will be releasing a fix for this. Nice catch! Thank you!

      September 15, 2016 at 11:57 am
  • Johan De Meersman

    Thank you for the excellent explanation, Kenny. For those interested, I’ve put a simple Ansible playbook to patch mysqld_safe at .

    September 15, 2016 at 11:41 am
    • Johan De Meersman

      I’ve updated the playbook to reflect Patrick’s catch of a flaw in the Percona patch. The playbook will take care of removing that patch first if you had already applied it.

      September 15, 2016 at 5:58 pm
  • Ricardo Abech

    So, If I am NOT running mysqld_safe (instead running default Mysqld on windows), am I affected by this CVE?


    September 19, 2016 at 9:40 am
    • Johan De Meersman

      Yes, the vulnerability is really in the MySQL server itself, which allows malicious code to write out files it shouldn’t be able to. If it can modify your configuration to include a malicious plugin, you are vulnerable. The mysqld_safe patch is really just a workaround to filter those out.
      (reposting as reply to post)

      September 19, 2016 at 10:10 am
  • soruzmanina

    The vulnerability of MySQL on windows system should be effective?

    September 23, 2016 at 7:08 am
  • anushri2

    This blog is the general information for the feature. You got a good work for these blog.We have a developing our creative content of this mind.Thank you for this blog. This for very interesting and useful.

    July 22, 2019 at 7:36 am

Comments are closed.

Use Percona's Technical Forum to ask any follow-up questions on this blog topic.