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/mysqld.pid --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 ld.so for details. set_malloc_lib() { malloc_lib="$1" if [ "$malloc_lib" = tcmalloc ]; then pkglibdir=`get_mysql_config --variable=pkglibdir` malloc_lib= # 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 tmp="$libdir/libtcmalloc$flavor.so" #log_notice "DEBUG: Checking for malloc lib '$tmp'" [ -r "$tmp" ] || continue malloc_lib="$tmp" break 2 done done [...] ----------[ eof ]--------------- which can be used to preload a shared library before starting the server. The library can be set with the following parameter: --malloc-lib=LIB 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 impossible. 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. [...]
This was already addressed with https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-db/mysql-init-scripts?id=c3bf8ff29ade3fd7eba1f1ca98a96d70558b3720 which became -2.1-r1 and stable via https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-db/mysql-init-scripts?id=8e47f129fdc29c3128e6031dd017b475b6772765 Maintainer(s), please drop the vulnerable versions: =dev-db/mysql-init-scripts-2.0-r1 =dev-db/mysql-init-scripts-2.1_alpha4
Old packages removed
@ Security: Please vote so that we can proceed and close this one.
(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.
This issue was resolved and addressed in GLSA 201701-01 at https://security.gentoo.org/glsa/201701-01 by GLSA coordinator Thomas Deutschmann (whissi).