Bug 1433010 (CVE-2016-5483, CVE-2017-3600)

Created community-mysql tracking bugs for this issue:

Affects: fedora-all [bug 1433350]

MariaDB upstream corrected this issue in versions 5.5.53, 10.0.28, and 10.1.19.  Therefore, MariaDB packages shipped in Red Hat Software Collections were fixed via the following errata:

mariadb55-mariadb:
  https://rhn.redhat.com/errata/RHSA-2016-2131.html

rh-mariadb100-mariadb:
  https://rhn.redhat.com/errata/RHSA-2016-2927.html

rh-mariadb101-mariadb:
  https://rhn.redhat.com/errata/RHSA-2016-2928.html

This CVE is actually for 2 issues.


* Incorrect handling of newline character when generating comments as part of the mysqldump output.  When such dump file is later processed by the mysql command (e.g. to restore database backup), arbitrary shell or SQL command is executed with the privileges of the user running mysql.

Reporter demonstrates the problem in his blog post using a specially-crafted table name.  A table created with this SQL statement:

  CREATE TABLE `evil
  \! id
  select user(),@@version/*` (test text);

will cause mysqldump to generate this comment:

  --
  -- Table structure for table `evil
  \! id
  select user(),@@version/*`  
  --

Lines 3 and 4 are not properly commented out and hence will be executed as additional commands.

Reporter also includes these options to mitigate this problem:

  - Use --skip-comments when using mysqldump
  - Revoke create table privileges wherever possible (best practice anyway)
  - Only dump table data instead of the structure in scheduled backups
  - Use an alternative tool to backup your mysql data

Out of the listed options, the use of --skip-comments seems to be the least invasive way to mitigate this problem, as the generated SQL dump can still be restored by mysql without any changes to the restore procedure, it only makes the output less human-readable.

The attack via specially crafted table name can only be executed by a database user with privileges to create tables.  This privilege is frequently granted to non-administrative users, limited to specific database(s) owned by those users.

Additional attack vectors seem to exist for users with higher privileges such as   privileges to create databases.


* Incorrect handling of database names with newline characters when they are used in the USE statement processed by the mysql tool.

Reporter's blog post demonstrates the issue with a database created as:

  CREATE DATABASE `test
  \! id
  select user(),@@version; -- -`

mysqldump, when creating backup of all databases, will include the following USE command in its output:

  USE `test
  \! id
  select user(),@@version; -- -`;

The mysql command handled lines 2 and 3 as separate commands and not as part of the name passed to the USE command.

Reporter provides these options to mitigate this issue:

  - Revoke create database privileges wherever possible, as is best practice
  - Do not use mysqldump as your SST method, xtrabackup-v2 is the reccomended
    method
  - Audit your databases for tables containing new lines. You can do this
    with a simple one-liner: find /var/lib/mysql -type d -name "*@000a*"

Unlike the first issue, this one can not be easily mitigated by the use of --skip-comments option passed to mysqldump.

On the other hand, this problem is triggered by a malicious database name, so attacker would need to have privileges to create databases to exploit this issue.  Such privilege is usually restricted to database administrative users.

Reporter also notes that in Galera deployments, this issue can be triggered even outside backup restore procedure if mysqldump wsrep_sst_method is configured.  The default method in mariadb-galera packages included in Red Hat products is rsync.

MySQL was fixed in versions 5.5.55, 5.6.36, and 5.7.18.

MySQL upstream commit:

https://github.com/mysql/mysql-server/commit/6fa5e0814662d691be1a29bf88332348ec7c50c9

Relevant release notes entry:

  mysqldump failed to properly quote certain identifiers in SQL statements
  written to the dump output. (Bug #25717383)

https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-18.html
https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-36.html
https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-55.html

It should be noted that the MySQL fixes linked in comment 5 only address the first problem descried in comment 4, but not the second one.

*** Bug 1443387 has been marked as a duplicate of this bug. ***

Oracle assigned a duplicates CVE-2017-3600 for this issue.

Mitre rejected CVE-2016-5483 in favor of CVE-2017-3600.

Name: CVE-2016-5483
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5483
Assigned: 20160616

** REJECT **
DO NOT USE THIS CANDIDATE NUMBER.  ConsultIDs: CVE-2017-3600.
Reason: This candidate is a reservation duplicate of CVE-2017-3600.
Notes: All CVE users should reference CVE-2017-3600 instead of this
candidate. All references and descriptions in this candidate have
been removed to prevent accidental usage.

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2017:2192 https://access.redhat.com/errata/RHSA-2017:2192

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.3 EUS

Via RHSA-2017:2787 https://access.redhat.com/errata/RHSA-2017:2787

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.3 EUS

Via RHSA-2017:2886 https://access.redhat.com/errata/RHSA-2017:2886

(In reply to Tomas Hoger from comment #5)
> MySQL was fixed in versions 5.5.55, 5.6.36, and 5.7.18.
> 
> MySQL upstream commit:
> 
> https://github.com/mysql/mysql-server/commit/6fa5e0814662d691be1a29bf88332348ec7c50c9

The fix_identifier_with_newline() function introduced in this commit was found to contain a buffer overflow that can be triggered via long mysqldump command line arguments, see CVE-2018-3070 / bug 1602369.