Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 Feb 2017 13:52:45 +0100
From: Tomas Hoger <>
To: Dawid Golunski <>
Subject: Re: MySQL / MariaDB / Percona - Root Privilege
 Escalation Exploit [ CVE-2016-6664 / CVE-2016-5617 ]

On Mon, 14 Nov 2016 14:36:16 -0200 Dawid Golunski wrote:

> Vulnerability: MySQL / MariaDB / PerconaDB - Root Privilege Escalation
> CVE-2016-6664 / (Oracle)CVE-2016-5617

The original MySQL fix for this issue was quite incomplete and easy to
bypass.  It had the following problems:

- Symlink check was racy - it was easy to replace log file created by
  touch by a symlink before chmod and chown was used.

- You could avoid the symlink check completely by directly setting
  log-error to the path name of the file you want to corrupt, such as:

  log-error = /etc/

- Symlink check did not cover hardlinks (this is a variant of the
  previous, sort of).

- Existing symlinks were used even if they were not chmoded / chowned
  any more, so it was possible to corrupt files with myslqd_safe's log

I reported these problems to Oracle, and they assigned CVE-2017-3312
for the incomplete fix.  They were addressed in the following commit:

Note that the commit pre-dates Oct 2016 CPU, when Oracle first
mentioned CVE-2016-6664 / CVE-2016-5617 as fixed, but it was only
included in MySQL 5.5.54, 5.6.35, and 5.7.17 released mid-Dec 2016, and
hence listed in Jan 2017 CPU.  The fix also pre-dates my report.

Dawid, I assume you were aware of these problems and reported them
too.  You're acknowledged as a reporter of (at least) one of the issues
in the Jan 2017 CPU:

and also in Percona Server release notes:

  mysqld_safe now limits the use of rm and chown to avoid privilege
  escalation. chown can now be used only for /var/log directory. Bug
  fixed #1660265. Thanks to Dawid Golunski (

Linked Percona bug is not public, but the above text matches MySQL
commit linked above.

As Oracle is refusing to publicly share any information about their
CVEs, can you, Dawid, provide information on what CVE or CVEs were
given to you by Oracle in response to your reports, and for what
issues?  If you've not received that information yet, would you mind
asking?  I suspect you may have some info to share on CVE-2017-3317 and

Besides the above, I also reported the following issues.  CVEs below
were assigned by Oracle.

CVE-2017-3265 unsafe chmod/chown use in the init script

These may allow mysql -> root privilege escalation similar to
CVE-2016-6664.  Fixed in:

CVE-2017-3291 was assigned to two independent issues

- unrestricted mysqld_safe's ledir

By setting ledir to say /tmp in my.cnf, you could make mysqld_safe
execute mysqld from there rather than some expected location
under /usr.  Besides mysql -> root escalation, this also could have
been used by non-mysql local users in combination with the
CVE-2016-6662 issue against MySQL versions that do not support
malloc-lib (e.g. MySQL 5.1).  Fixed in:

- insecure path use in mysqld_safe

This code tries to find my_print_defaults command:

It first tries relative to $MY_BASEDIR_VERSION, which could have been
set to $PWD:

If root ran mysqld_safe while their $PWD was /tmp, arbitrary code
controlled by some unprivileged local (not necessarily mysql) user
could have been executed.  This was fixed in:

There are few more related problems fixed in Jan 2017 CPU, but as noted
above, Oracle refuses to acknowledge mapping to CVEs publicly.

Tomas Hoger / Red Hat Product Security

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ