Sep
15
2016
--

Percona XtraDB Cluster 5.6.30-25.16.2 is now available (CVE-2016-6662 fix)

Percona XtraDB Cluster Reference Architecture

Percona XtraDB Cluster 5.6

Percona  announces the new release of Percona XtraDB Cluster 5.6 on September 15, 2016. Binaries are available from the downloads area or our software repositories.

Percona XtraDB Cluster 5.6.30-25.16.2 is now the current release, based on the following:

  • Percona Server 5.6.30-76.3
  • Galera Replication library 3.16
  • Codership wsrep API version 25

This release provides a fix for CVE-2016-6662. More information about this security issue can be found here.

Bug Fixed:

  • Due to security reasons ld_preload libraries can now only be loaded from the system directories (/usr/lib64, /usr/lib) and the MySQL installation base directory.

Help us improve our software quality by reporting any bugs you encounter using our bug tracking system. As always, thanks for your continued support of Percona!

Sep
12
2016
--

Is Your Database Affected by CVE-2016-6662?

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 legalhackers.com 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. Improper OS files/directories permissions around MySQL configuration files that allow the MySQL system user access to modify or create new configuration files.
  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

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: 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
    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)

Powered by WordPress | Theme: Aeros 2.0 by TheBuckmaker.com