Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 593618 - <dev-db/mysql-init-scripts-2.1-r1: systemd unit uses mysqld_safe which allows privilege escalation after exploiting CVE-2016-6662
Summary: <dev-db/mysql-init-scripts-2.1-r1: systemd unit uses mysqld_safe which allows...
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
Whiteboard: B1 [glsa]
Depends on:
Blocks: CVE-2016-6662
  Show dependency tree
Reported: 2016-09-12 20:36 UTC by Thomas Deutschmann (RETIRED)
Modified: 2017-01-01 13:37 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Deutschmann (RETIRED) gentoo-dev 2016-09-12 20:36:42 UTC
From $URL:

The default MySQL package comes with a mysqld_safe script which is used by many
default installations/packages of MySQL as a wrapper to start the MySQL service 
process which can observed, for example, in case of the following fully-updated
Debian system:

root@debian:~# lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 8.5 (jessie)
Release:	8.5
Codename:	jessie

root@debian:~# dpkg -l | grep -i mysql-server
ii  mysql-server                        5.5.50-0+deb8u1
ii  mysql-server-5.5                    5.5.50-0+deb8u1
ii  mysql-server-core-5.5               5.5.50-0+deb8u1

After starting MySQL (installed from packages provided in the default Debian repositories) by running

root@debian:~# service mysql start

or, alternatively:

root@debian:~# /etc/init.d/mysql start

The MySQL server process tree looks as follows:

root     14967  0.0  0.1   4340  1588 ?        S    06:41   0:00 /bin/sh /usr/bin/mysqld_safe

mysql    15314  1.2  4.7 558160 47736 ?        Sl   06:41   0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --log-error=/var/log/mysql/error.log --pid-file=/var/run/mysqld/ --socket=/var/run/mysqld/mysqld.sock --port=3306

As can be seen, the mysqld_safe wrapper script is executed as root, whereas the
main mysqld process drops its privileges to mysql user.

The wrapper script has the following function :

----[ /usr/bin/mysqld_safe ]----


# set_malloc_lib LIB
# - If LIB is empty, do nothing and return
# - If LIB is 'tcmalloc', look for tcmalloc shared library in /usr/lib
#   then pkglibdir.  tcmalloc is part of the Google perftools project.
# - If LIB is an absolute path, assume it is a malloc shared library
# Put LIB in mysqld_ld_preload, which will be added to LD_PRELOAD when
# running mysqld.  See for details.
set_malloc_lib() {

  if [ "$malloc_lib" = tcmalloc ]; then
    pkglibdir=`get_mysql_config --variable=pkglibdir`
    # This list is kept intentionally simple.  Simply set --malloc-lib
    # to a full path if another location is desired.
    for libdir in /usr/lib "$pkglibdir" "$pkglibdir/mysql"; do
      for flavor in _minimal '' _and_profiler _debug; do
        #log_notice "DEBUG: Checking for malloc lib '$tmp'"
        [ -r "$tmp" ] || continue
        break 2


----------[ eof ]---------------

which can be used to preload a shared library before starting the server.

The library can be set with the following parameter:


This parameter can also be specified within a mysql config file (my.cnf) 
in a '[mysqld]' or '[mysqld_safe]' section.

If an attacker managed to inject a path to their malicious library within the 
config, they would be able to preload an arbitrary library and thus execute 
arbitrary code with root privileges when MySQL service is restarted (manually,
via a system update, package update, system reboot etc.)

In 2003 a vulnerability was disclosed in MySQL versions before 3.23.55 that 
allowed users to create mysql config files with a simple statement:

SELECT * INFO OUTFILE '/var/lib/mysql/my.cnf'

The issue was fixed by refusing to load config files with world-writable
permissions as these are the default permissions applied to files created
by OUTFILE query.
As an additional protection, OUTFILE/DUMPFILE statements are prohibited from
overwrite existing files. 
This protects existing configuration files. 
The old vulnerability has been considered fixed ever since the MySQL 3.23.55 
was released in 2003, and writing to configuration files has been considered 

However, the V. PROOF OF CONCEPT section below will show that it is possible to
successfully bypass current restrictions by abusing MySQL logging functions 
(available in every MySQL install by default) to achieve the following:

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

2) Create 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) Attackers with only SELECT/FILE permissions can gain access to logging 
functions (normally only available to MySQL admin users) on all of the 
_default_ MySQL installations and thus be in position to add/modify MySQL 
config files.
Comment 1 Thomas Deutschmann (RETIRED) gentoo-dev 2016-09-13 18:11:16 UTC
This was already addressed with which became -2.1-r1 and stable via

Maintainer(s), please drop the vulnerable versions:
Comment 2 Brian Evans (RETIRED) gentoo-dev 2016-09-14 16:09:27 UTC
Old packages removed
Comment 3 Thomas Deutschmann (RETIRED) gentoo-dev 2016-11-18 18:59:43 UTC
@ Security: Please vote so that we can proceed and close this one.
Comment 4 Aaron Bauman (RETIRED) gentoo-dev 2016-11-19 05:23:28 UTC
(In reply to Thomas Deutschmann from comment #3)
> @ Security: Please vote so that we can proceed and close this one.

Really no voting needs to be done.  This will be addressed along with the TRACKER bug, but we must ensure to capture all the affected packages when the GLSA is written.
Comment 5 GLSAMaker/CVETool Bot gentoo-dev 2017-01-01 13:37:29 UTC
This issue was resolved and addressed in
 GLSA 201701-01 at
by GLSA coordinator Thomas Deutschmann (whissi).