This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1375198 - (CVE-2016-6662) CVE-2016-6662 mysql: general_log can write to configuration files, leading to privilege escalation (CPU Oct 2016)
CVE-2016-6662 mysql: general_log can write to configuration files, leading to...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
impact=important,public=20160912,repo...
: Security
Depends On: 1375202 1375200 1375201 1377974 1379492 1379493 1379494 1379495 1379496 1379497 1379498 1379499 1384960 1384961 1384962 1384963 1386744 1386745 1393306 1393309 1393313 1393314 1397309 1397310 1429972 1429973
Blocks: 1386598 1323912 1375204
  Show dependency treegraph
 
Reported: 2016-09-12 09:16 EDT by Adam Mariš
Modified: 2017-03-07 10:23 EST (History)
60 users (show)

See Also:
Fixed In Version: mysql 5.5.52, mysql 5.6.33, mysql 5.7.15, mariadb 5.5.51, mariadb 10.0.27, mariadb 10.1.17
Doc Type: If docs needed, set a value
Doc Text:
It was discovered that the MySQL logging functionality allowed writing to MySQL configuration files. An administrative database user, or a database user with FILE privileges, could possibly use this flaw to run arbitrary commands with root privileges on the system running the database server.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-01-24 07:00:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Mariš 2016-09-12 09:16:58 EDT
A vulnerability in MySQL was found that allows:

1. injecting malicious configuration into existing MySQL configuration files on systems with weak/improper permissions (configs owned by/writable by mysql user)

2. creating new configuration files within a MySQL data directory (writable by MySQL by default) on _default_ MySQL installs without the need to rely on improper config permisions.

3. gaining access to logging functions (normally only available to MySQL admin users) to attackers with only SELECT/FILE permissions on all of the default_ MySQL installations and thus be in position to add/modify MySQL config files.

Public via:

http://seclists.org/oss-sec/2016/q3/481

External References:

https://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.txt
Comment 1 Adam Mariš 2016-09-12 09:18:06 EDT
Created mariadb tracking bugs for this issue:

Affects: fedora-all [bug 1375201]
Comment 2 Adam Mariš 2016-09-12 09:18:22 EDT
Created community-mysql tracking bugs for this issue:

Affects: fedora-all [bug 1375200]
Comment 3 Adam Mariš 2016-09-12 09:18:34 EDT
Created mariadb-galera tracking bugs for this issue:

Affects: fedora-all [bug 1375202]
Comment 4 Tomas Hoger 2016-09-12 18:00:01 EDT
MariaDB upstream bug report:

https://jira.mariadb.org/browse/MDEV-10465

It does not have any details on how this bug was addressed, but its id can be used to locate relevant commits in changelogs for the versions listed as correcting this issue:

https://mariadb.com/kb/en/mariadb/mariadb-5551-changelog/
https://mariadb.com/kb/en/mariadb/mariadb-10027-changelog/
https://mariadb.com/kb/en/mariadb/mariadb-10117-changelog/

These link the following commits as related to MDEV-10465:

https://github.com/MariaDB/server/commit/470f259
https://github.com/MariaDB/server/commit/2a54a53
https://github.com/MariaDB/server/commit/0098d78

These commits prevent general_log from writing into files with names ending with my.cnf or my.ini.
Comment 5 Tomas Hoger 2016-09-12 18:10:51 EDT
MySQL seems to be fixed in versions 5.5.52, 5.6.33, and 5.7.15:

https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-52.html
https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-33.html
https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-15.html

The following changes are described, corresponding to the linked commits:

  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)

https://github.com/mysql/mysql-server/commit/684a165f28b3718160a3e4c5ebd18a465d85e97c
https://github.com/mysql/mysql-server/commit/754e7eff2872995e2b6e62f9da7448587a411c7b

  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)

https://github.com/mysql/mysql-server/commit/48bd8b16fe382be302c6f0b45931be5aa6f29a0e

The second change is similar to MariaDB fix, but is more strict by preventing overwrite of any file ending with .cnf or .ini.

MySQL 5.7.15 also includes this additional change:

  mysqld_safe attempted to read my.cnf in the data directory, although
  that is no longer a standard option file location. (Bug #24482156)

https://github.com/mysql/mysql-server/commit/71f48ab393bce80a59e5a2e498cd1f46f6b43f9a

Oracle is probably not going to acknowledge these fixes with CVEs until the next CPU scheduled for mid-October.
Comment 12 Tomas Hoger 2016-09-14 17:40:22 EDT
All MySQL and MariaDB packages in Red Hat Enterprise Linux and Red Hat Software Collections install my.cnf configuration file as root-owned and not writeable to the mysql user under which mysqld is run.  The configuration file is created in /etc and not inside the data directory.

All MySQL and MariaDB packages in at least Red Hat Enterprise Linux 6 and later, and Red Hat Software Collections allow database users with FILE privileges to create my.cnf file inside data directory that is not world-writeable, and hence is not ignored by mysqld / mysqld_safe.

All MySQL and MariaDB packages for Red Hat Enterprise Linux 7 (either directly from Red Hat Enterprise Linux 7 or from Red Hat Software Collections for Red Hat Enterprise Linux 7) run mysqld_safe with mysql user privileges and not root privileges.  Therefore, the worst impact of this issue on Red Hat Enterprise Linux 7 is escalation form database user with FILE privileges to arbitrary code execution as mysql system user.  Additionally, the init script / systemd unit for rh-mariadb101 collection for Red Hat Enterprise Linux 7 does not use mysqld_safe at all and is therefore not vulnerable to the published exploit.

The MySQL 5.1 packages in Red Hat Enterprise Linux 6 include the version of mysqld_safe that does not implement support for library preloading.  Therefore, the published remote exploit does not affect those packages.  Note that there is still a possibility of local privilege escalation - a database user with FILE privileges that also has local unprivileged shell access can escalate their privileges to root.

For certain MySQL / MariaDB packages running on Red Hat Enterprise Linux 7, the issue is further mitigated by SELinux, which prevents loading of the injected shared library.

Mitigating factors:

- The attack can only be performed by an attacker with database access with FILE privileges.  The FILE privilege is not commonly granted to non-administrative database users, and as noted in the reporter's advisory, it allows gaining full administrative privileges (unless restricted with the secure_file_priv setting).  As noted in the advisory, SQL injection flaws in web applications may open up this issue to attackers who are not meant to have direct database access.  Ensure that the FILE privilege is not granted to any non-administrative database user.  Note that reporter claims existence of another, not yet disclosed vulnerability which makes exploitation of this issue possible without FILE privilege.  The CVE-2016-6663 was reserved for the additional vulnerability.

- Published exploit depends on an already existing my.cnf that is writeable to the mysql user.  As noted above, in the default configuration of MySQL/MariaDB packages in Red Hat Enterprise Linux and Red Hat Software Collections, the configuration file is not writeable to the mysql user.  While the advisory describes how to create a new my.cnf in the data directory that is read by mysqld / mysqld_safe, the newly created file is rejected as malformed as it does not start with a valid INI file section delimiter.  The advisory does not mention any way to avoid this exploitation obstacle.

The combination of the above two factors imply that the published exploit does not work against the default configuration of MySQL and MariaDB in Red Hat products.
Comment 13 Stefan Cornelius 2016-09-15 06:12:14 EDT
Statement:

All MySQL and MariaDB packages in Red Hat Enterprise Linux and Red Hat Software Collections install the my.cnf configuration file in /etc as root-owned and not writeable to mysqld's mysql user. This default configuration stops the published exploit for this issue.

All MySQL and MariaDB packages for Red Hat Enterprise Linux 7 (either those directly included in Red Hat Enterprise Linux 7 or from Red Hat Software Collections for Red Hat Enterprise Linux 7) run mysqld_safe with mysql user privileges and not root privileges, limiting the potential impact to code execution as mysql system user.

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.

For additional details, refer to:

https://bugzilla.redhat.com/show_bug.cgi?id=1375198#c12


Mitigation:

- Ensure all MySQL / MariaDB configuration files are not writeable to the mysql user. This is the default configuration in Red Hat products.

- Ensure that non-administrative database users are not granted FILE privilege. Applications accessing data in MySQL / MariaDB databases, including web application potentially vulnerable to SQL injections, should use database accounts with the lowest privileges required.

- If FILE permission needs to be granted to some non-administrative database users, use secure_file_priv setting to limit where files can be written to or read from.
Comment 14 Tomas Hoger 2016-09-16 04:10:13 EDT
(In reply to Tomas Hoger from comment #12)
> The MySQL 5.1 packages in Red Hat Enterprise Linux 6 include the version of
> mysqld_safe that does not implement support for library preloading. 
> Therefore, the published remote exploit does not affect those packages.
 
The same applies to MySQL 5.0 packages in Red Hat Enterprise Linux 5.  Additionally, MySQL 5.0 does not support general_log, which is also required by this exploit.  The support for general_log was added in version 5.1.29:

  Important Change: The --log option now is deprecated and will be removed
  (along with the log system variable) in the future. Instead, use the
  --general_log option to enable the general query log and the
  --general_log_file=file_name option to set the general query log file name.
  The values of these options are available in the general_log and
  general_log_file system variables, which can be changed at runtime.

  http://downloads.mysql.com/docs/mysql-5.1-relnotes-en.pdf

As hinted by the above, --log could not be changed at runtime.
Comment 18 Gerald Prock 2016-09-21 01:38:56 EDT
It seams, that the bug is already abused in the wild.

We have some LAMP server with infected configuration files in the /var/lib/mysql/ folder and with the logrotate the restart fails. At the moment we have been lucky and there was no link to a *.so file but otherwise the mysql_safe would load them on start with root permissions.

Example for RHEL7:
---------------------------------------
1) Write file to /var/lib/mysql/my.cnf als user:

$ mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 17828
Server version: 5.5.47-MariaDB MariaDB Server

Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> 
MariaDB [(none)]> set global general_log_file = '/var/lib/mysql/my.cnf';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> set global general_log = on;
Query OK, 0 rows affected (0.02 sec)

MariaDB [(none)]> select 'blablablub ... i kill the restart ... ggg';
+-------------------------------------------+
| blablablub ... i kill the restart ... ggg |
+-------------------------------------------+
| blablablub ... i kill the restart ... ggg |
+-------------------------------------------+
1 row in set (0.00 sec)

MariaDB [(none)]> set global general_log = off;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> quit
Bye

---------------------------------------
2) Content of the created file:

$ cat /var/lib/mysql/my.cnf 
/usr/libexec/mysqld, Version: 5.5.47-MariaDB (MariaDB Server). started with:
Tcp port: 3306  Unix socket: /var/lib/mysql/mysql.sock
Time                 Id Command    Argument
160920 16:07:21	17828 Query	select 'blablablub ... i kill the restart ... ggg'
160920 16:07:33	17828 Query	set global general_log = off

---------------------------------------
3) Restart of the database:

# systemctl restart mariadb
Job for mariadb.service failed because the control process exited with error code. See "systemctl status mariadb.service" and "journalctl -xe" for details.

---------------------------------------
4) Log of the start:

# systemctl status mariadb.service
● mariadb.service - MariaDB database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Tue 2016-09-20 16:08:49 CEST; 9s ago
  Process: 12779 ExecStartPost=/usr/libexec/mariadb-wait-ready $MAINPID (code=exited, status=1/FAILURE)
  Process: 12778 ExecStart=/usr/bin/mysqld_safe --basedir=/usr (code=exited, status=0/SUCCESS)
  Process: 12750 ExecStartPre=/usr/libexec/mariadb-prepare-db-dir %n (code=exited, status=0/SUCCESS)
 Main PID: 12778 (code=exited, status=0/SUCCESS)

Sep 20 16:08:48 rhel7test.vtirol.local mysqld_safe[12778]: Fatal error in defaults handling. Program aborted
Sep 20 16:08:48 rhel7test.vtirol.local mysqld_safe[12778]: error: Found option without preceding group in config file: /var/lib/mysql/my.cnf at line: 1
Sep 20 16:08:48 rhel7test.vtirol.local mysqld_safe[12778]: Fatal error in defaults handling. Program aborted
Sep 20 16:08:48 rhel7test.vtirol.local mysqld_safe[12778]: 160920 16:08:48 mysqld_safe Logging to '/var/lib/mysql/rhel7test.vtirol.local.err'.
Sep 20 16:08:48 rhel7test.vtirol.local mysqld_safe[12778]: 160920 16:08:48 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
Sep 20 16:08:48 rhel7test.vtirol.local mysqld_safe[12778]: 160920 16:08:48 mysqld_safe mysqld from pid file /var/lib/mysql/rhel7test.vtirol.local.pid ended
Sep 20 16:08:49 rhel7test.vtirol.local systemd[1]: mariadb.service: control process exited, code=exited status=1
Sep 20 16:08:49 rhel7test.vtirol.local systemd[1]: Failed to start MariaDB database server.
Sep 20 16:08:49 rhel7test.vtirol.local systemd[1]: Unit mariadb.service entered failed state.
Sep 20 16:08:49 rhel7test.vtirol.local systemd[1]: mariadb.service failed.

---------------------------------------

As you see the mysqld_safe is reading the file /var/lib/mysql/my.cnf on startup.
It also works with /var/lib/mysql/.my.cnf and with a ~/.my.cnf file.

As hotfix a root owned file with 644 in all of the folders would work. But how to identify all folders the database is looking on startup? It would be nice if the rpm would contain that empty files ...
Comment 21 Tomas Hoger 2016-09-22 16:58:35 EDT
(In reply to Gerald Prock from comment #18)
> It seams, that the bug is already abused in the wild.
> 
> We have some LAMP server with infected configuration files in the
> /var/lib/mysql/ folder and with the logrotate the restart fails. At the
> moment we have been lucky and there was no link to a *.so file

For this attack, attacker needs to have ability to execute arbitrary SQL queries.  Have you figured out how they were able to do so, as that's likely an issue of its own?  Do you have untrusted DB users with high privileges, or vulnerable web app which also connects to DB using a privileged DB account?

> but otherwise the mysql_safe would load them on start with root permissions.
> 
> Example for RHEL7:

Your example is on RHEL-7, where mysqld_safe is not run with root permissions, but as mysql OS user.  See above for details.

> 1) Write file to /var/lib/mysql/my.cnf als user:
> 
> $ mysql

It seems you're connecting as DB admin / root.  Comments above note that DB user with sufficient privileges can create new my.cnf file inside of the data directory.  That file is read by mysqld, and as it's not valid INI file, it leads to the service restart failure as you describe.
Comment 29 Tomas Hoger 2016-09-28 05:11:22 EDT
Reporter's advisory (linked in comment 0) has been updated few times since the original publication.  The most notable changes include:

* The list of affected MySQL versions was updated to note that the issue was fixed in versions 5.5.52, 5.6.33, and 5.7.15, as noted in comment 5 above.

* Author now more explicitly claims that even though published exploit requires existing my.cnf file that is writeable to the mysql system user, there is a different exploit that has not been published yet, which does not require existing my.cnf with weak permissions.

Advisory explains that it is possible to create new my.cnf file in the data directory, which has to be writeable to the mysql user.  Such file does not typically exist.  When created using the general_log mechanism used by the exploit, it will not start with INI file [section] label, causing it to be rejected by MySQL as invalid and its content ignored.  It is unclear if a mechanism used to create a well-formed my.cnf using MySQL logging would be classified as a separate vulnerability.

The advisory includes the following mitigation instructions:

  As temporary mitigations, users should ensure that no mysql config files
  are owned by mysql user, and create root-owned dummy my.cnf files that
  are not in use.
  These are by no means a complete solution and users should apply official
  vendor patches as soon as they become available.

It is unclear why this contradicting information is given, and if the private exploit can work if root-owned my.cnf exist in the data directory.
Comment 30 Tomas Hoger 2016-09-28 05:33:28 EDT
Various MySQL and MariaDB packages in Red Hat Enterprise Linux and Red Hat Software Collections may different default locations for the data directory.  A subset of these files are used by each version:

/var/lib/mysql/.my.cnf
/var/lib/mysql/my.cnf
/opt/rh/mysql55/root/var/lib/mysql/my.cnf
/var/opt/rh/rh-mysql56/lib/mysql/my.cnf
/opt/rh/mariadb55/root/var/lib/mysql/my.cnf
/var/opt/rh/rh-mariadb100/lib/mysql/my.cnf
/var/opt/rh/rh-mariadb101/lib/mysql/my.cnf

Creating the above files if their parent directory exists on a system as root-owned and not writeable to the mysql user follows the mitigation advice from the reporter's advisory.
Comment 33 Fedora Update System 2016-10-03 16:20:15 EDT
mariadb-10.0.27-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 34 errata-xmlrpc 2016-10-13 10:04:17 EDT
This issue has been addressed in the following products:

  Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) for RHEL 7

Via RHSA-2016:2061 https://rhn.redhat.com/errata/RHSA-2016-2061.html
Comment 35 errata-xmlrpc 2016-10-13 10:05:18 EDT
This issue has been addressed in the following products:

  Red Hat OpenStack Platform 9.0 (Mitaka)

Via RHSA-2016:2062 https://rhn.redhat.com/errata/RHSA-2016-2062.html
Comment 36 errata-xmlrpc 2016-10-13 10:14:03 EDT
This issue has been addressed in the following products:

  Red Hat Enterprise Linux OpenStack Platform 5.0 (Icehouse) for RHEL 7

Via RHSA-2016:2059 https://rhn.redhat.com/errata/RHSA-2016-2059.html
Comment 37 errata-xmlrpc 2016-10-13 10:34:10 EDT
This issue has been addressed in the following products:

  Red Hat Enterprise Linux OpenStack Platform 6.0 (Juno) for RHEL 7

Via RHSA-2016:2060 https://rhn.redhat.com/errata/RHSA-2016-2060.html
Comment 38 errata-xmlrpc 2016-10-13 15:35:41 EDT
This issue has been addressed in the following products:

  Red Hat Enterprise Linux OpenStack Platform 5.0 (Icehouse) for RHEL 6

Via RHSA-2016:2058 https://rhn.redhat.com/errata/RHSA-2016-2058.html
Comment 39 Tomas Hoger 2016-10-14 08:13:34 EDT
Additional related changes appeared in MySQL versions 5.5.53, 5.6.34, and 5.7.16.  Those versions change change the default for secure_file_priv, the setting which controls where database user with FILE privileges can write files.  Depending on the build, it's either NULL (preventing use of FILE privilege), or an empty dedicated directory that is created by Oracle distributed binary packages.  Additionally, mysqld now tries to detect insecure secure_file_priv setting at startup and refuse to start if it's insecure.  The following settings are considered insecure:

- empty secure_file_priv, allowing read/write to any directory
- secure_file_priv pointing to data directory or its subdirectory
- secure_file_priv pointing to directory accessible to all users

http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-53.html
http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-34.html
http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-16.html

This commit adds these changes:

https://github.com/mysql/mysql-server/commit/7cb79a65ba6286ac66d5ebbebea3243ef97f5c41
Comment 42 Tomas Hoger 2016-10-18 17:22:27 EDT
This CVE is not mentioned in the Oracle CPU Oct 2016:

http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html#AppendixMSQL

Note that the CPU lists version 5.5.52, 5.6.33, and 5.7.15 as affected by this issue despite fixes that were applied in those versions - see comment 5.  Apparently, changes applied in versions 5.5.53, 5.6.34, and 5.7.16 - see comment 39 - got all listed under the original CVE.
Comment 43 errata-xmlrpc 2016-10-18 19:06:03 EDT
This issue has been addressed in the following products:

  Red Hat OpenStack Platform 8.0 (Liberty)

Via RHSA-2016:2077 https://rhn.redhat.com/errata/RHSA-2016-2077.html
Comment 46 errata-xmlrpc 2016-10-31 15:53:18 EDT
This issue has been addressed in the following products:

  Red Hat Software Collections for Red Hat Enterprise Linux 6
  Red Hat Software Collections for Red Hat Enterprise Linux 6.6 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7
  Red Hat Software Collections for Red Hat Enterprise Linux 7.1 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7.2 EUS

Via RHSA-2016:2130 https://rhn.redhat.com/errata/RHSA-2016-2130.html
Comment 47 errata-xmlrpc 2016-10-31 18:23:41 EDT
This issue has been addressed in the following products:

  Red Hat Software Collections for Red Hat Enterprise Linux 6
  Red Hat Software Collections for Red Hat Enterprise Linux 6.6 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7
  Red Hat Software Collections for Red Hat Enterprise Linux 7.1 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7.2 EUS

Via RHSA-2016:2131 https://rhn.redhat.com/errata/RHSA-2016-2131.html
Comment 48 errata-xmlrpc 2016-11-03 16:50:47 EDT
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2016:2595 https://rhn.redhat.com/errata/RHSA-2016-2595.html
Comment 52 errata-xmlrpc 2016-11-15 06:30:28 EST
This issue has been addressed in the following products:

  Red Hat Software Collections for Red Hat Enterprise Linux 6
  Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7
  Red Hat Software Collections for Red Hat Enterprise Linux 7.1 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7.2 EUS

Via RHSA-2016:2749 https://rhn.redhat.com/errata/RHSA-2016-2749.html
Comment 53 Vignesh 2016-11-21 11:59:49 EST
(In reply to Stefan Cornelius from comment #13)
> Statement:
> 
> All MySQL and MariaDB packages in Red Hat Enterprise Linux and Red Hat
> Software Collections install the my.cnf configuration file in /etc as
> root-owned and not writeable to mysqld's mysql user. This default
> configuration stops the published exploit for this issue.
> 
> All MySQL and MariaDB packages for Red Hat Enterprise Linux 7 (either those
> directly included in Red Hat Enterprise Linux 7 or from Red Hat Software
> Collections for Red Hat Enterprise Linux 7) run mysqld_safe with mysql user
> privileges and not root privileges, limiting the potential impact to code
> execution as mysql system user.
> 
> 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.
> 
> For additional details, refer to:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1375198#c12
> 
> 
> Mitigation:
> 

Confused if these mitigations are also applicable for MySQL versions >= 5.5.53, 5.6.34, and 5.7.16 too which have the MySQL fix (per https://bugzilla.redhat.com/show_bug.cgi?id=1375198#c5).

> - Ensure all MySQL / MariaDB configuration files are not writeable to the
> mysql user. This is the default configuration in Red Hat products.
> 
Based on new fix, Even if they are writeable by mysql user (per file permissions), general query log and slow query log can no longer be written to a file ending with .ini or .cnf

> - Ensure that non-administrative database users are not granted FILE
> privilege. Applications accessing data in MySQL / MariaDB databases,
> including web application potentially vulnerable to SQL injections, should
> use database accounts with the lowest privileges required.
> 
Based on new fix, Even if non-admin database users are granted FILE privilege, they won't be able to write into .ini or .cnf files.

> - If FILE permission needs to be granted to some non-administrative database
> users, use secure_file_priv setting to limit where files can be written to
> or read from.

As I understand, the fix MySQL versions 5.5.53, 5.6.34, and 5.7.16, mitigates this issue completely and there is no need for any additional mitigations. Am I missing something?
Comment 56 errata-xmlrpc 2016-12-08 11:06:20 EST
This issue has been addressed in the following products:

  Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7.3 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 6
  Red Hat Software Collections for Red Hat Enterprise Linux 7
  Red Hat Software Collections for Red Hat Enterprise Linux 7.2 EUS

Via RHSA-2016:2928 https://rhn.redhat.com/errata/RHSA-2016-2928.html
Comment 57 errata-xmlrpc 2016-12-08 11:12:26 EST
This issue has been addressed in the following products:

  Red Hat Software Collections for Red Hat Enterprise Linux 6
  Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7
  Red Hat Software Collections for Red Hat Enterprise Linux 7.2 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7.3 EUS

Via RHSA-2016:2927 https://rhn.redhat.com/errata/RHSA-2016-2927.html
Comment 58 errata-xmlrpc 2017-01-24 06:45:52 EST
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2017:0184 https://rhn.redhat.com/errata/RHSA-2017-0184.html

Note You need to log in before you can comment on or make changes to this bug.