Ensuring continuity and open collaboration

MariaDB Server versions and the Remote Root Code Execution Vulnerability CVE-2016-6662

During the recent days there has been quite a lot of questions and discussion around a vulnerability referred to as MySQL Remote Root Code Execution / Privilege Escalation 0day with CVE code CVE-2016-6662. It’s a serious vulnerability and we encourage every MariaDB Server user to read the below update on the vulnerability from a MariaDB point of view.

The vulnerability can be exploited by both local and remote users. Both an authenticated connection to or SQL injection in an affected version of MariaDB Server can be used to exploit the vulnerability. If successful, a library file could be loaded and executed with root privileges. The vulnerability makes use of the mysqld_safe startup script.

However, if the database user being used has neither SUPER nor FILE privilege or if the user has FILE but –secure-file-priv is set to isolate the location of import and export operations, the vulnerability is NOT exploitable. It is always recommended configuration to not grant SUPER privileges and avoiding granting FILE privileges without using –secure-file-priv.

Users that have installed MariaDB Server 10.1.8 or later from RPM or DEB packages are not affected by the vulnerability. This is due to the fact that in version 10.1.8, we started using systemd instead of init to manage the MariaDB service. In this case the mysqld_safe startup script isn’t used.

The corresponding bug about the vulnerability can be seen in MariaDB’s project tracking with bug number MDEV-10465. It was opened on July 31st this year.

All stable MariaDB versions (5.5, 10.0, 10.1) were fixed in August in the following versions:

If you’re on any of the above versions (or later) you’re protected against this vulnerability.

If you happen to be testing an alpha version of 10.2, please be aware that the fix will be available in version 10.2.2. It is not available as of writing, but about to be released.

For the complete report of the vulnerability, please refer to the advisory by Dawid Golunski (legalhackers.com) who discovered the vulnerability.

8 Comments

  1. 2016-09-13    

    Thanks for the clarification info 🙂

    > This is due to the fact that in version 10.1.8, we started using systemd instead of init to manage the MariaDB service.

    But CentOS 6/RHEL6 would still use init though.

    • rasmus rasmus
      2016-09-14    

      If that is the case then CentOS 6/RHEL6 users should upgrade immediately.

  2. roidelapluie roidelapluie
    2016-09-14    

    > However, if the database user being used has neither SUPER nor FILE privilege or if the user has FILE but –secure-file-priv is set to isolate the location of import and export operations, the vulnerability is NOT exploitable.

    That is not true for the part with the general_log_file, is it?

    • rasmus rasmus
      2016-09-14    

      Adding the discussion from IRC as an answer to this:
      serg: one needs SUPER to modify @@general_log_file
      roidelapluie: Ok
      serg: without SUPER one can use FILE to get himself SUPER
      serg: that’s why it’s recommended to use –secure-file-priv to prevent direct file access to the datadir
      roidelapluie: But it means that the sentence is not true; a remote user with SUPER can execute arbitrary code
      serg: the sentence says that if the user does NOT have SUPER, then the vulnerability is NOT exploitable
      roidelapluie: ok

  3. 2016-09-14    

    I use Server version: 5.5.49-MariaDB MariaDB Server. Do I need to upgrade to version 5.5.51 to protect website? please give me advise. Thanks

    • rasmus rasmus
      2016-09-14    

      Yes, you should upgrade. Notice that 5.5.52 is available since yesterday.

      • 2016-09-15    

        WARNING: On our Debian server MariaDB auto updated this morning to 5.5.52, and then broke the server.
        The /var/lib/mysql folder was left with an unknown group and 700 privileges, hence no database
        access.

        • 2016-09-15    

          retract comment – wrong information. The MariaDB servers updated smoothly, The MySQL one did not.

Leave a Reply

Your email address will not be published. Required fields are marked *

Sponsors

MariaDB Foundation sponsors

Tweets by @mariadb

Code statistics