MySQL server versions 4.1.18 and below and 5.0.20 and below suffer from an information leakage issue.
eb1d10694aff57e15a622b021c3784bf24605040a4da6933d54eafaa3b59792c
~.oOOo. Anonymous Login Handshake .oOOo.~
=========================================
MySQL Server (<= 4.1.18, 5.0.20 ) has an information
leakage in the way mysql parses login packets on anonymous
users (blank password).
Author: Stefano Di Paola
Vulnerable: Mysql <= 4.1.18, 5.0.20
Type of Vulnerability: Local/Remote - input validation - Information
Leakage
Tested On : Debian 3.1 - IA32.
Vendor Status: Notified on April, 25th 2006, Confirmed on April, 26th
2006, New versions released on 2nd May 2006.
Fixed: Update to 4.0.27, 4.1.19, 5.0.21, 5.1.10 versions.
A Proof of Concept is Attached for this issue.
Tested on: Debian 3.1 - IA32.
A little Note:
To take advantage of these flaws an attacker should have direct access
to MySQL server communication layer (port 3306 or unix socket).
But if used in conjuction with some web application flaws
(i.e. php code injection) an attacker could use socket programming
(i.e. php sockets) to gain access to that layer.
-- Description
By crafting a specifically malformed login packet, initial db name is
filled with uninitialized memory content.
Let's suppose MySql Server has anonymous access.
Infact, if we want to use 'wisecdb' database as user 'wisec' and
password 's' a normal client would send a packet like this:
---------------------------------------------------------------
43 00 00 01 0d a6 03 00 00 00 00 01 08 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 77 69 73 65 63 00 14 aa 69 23 07 2a
ff 99 61 a3 c4 5f 04 66 3b 32 ef a1 f2 b6 59 77
69 73 65 63 64 62 00
C . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . w i s e c . . . i # . *
. . a . . _ . f ; 2 . . . . Y w
i s e c d b .
---------------------------------------------------------------
but if we look at the code (MySQL <= 5.0.20)
on sql_parse.cc line ~ 993
function check_connection(THD *thd):
--
char *user= end;
char *passwd= strend(user)+1;
char *db= passwd;
char db_buff[NAME_LEN+1]; // buffer to store db in
utf8
char user_buff[USERNAME_LENGTH+1]; // buffer to store user
in utf8
uint dummy_errors;
uint passwd_len= thd->client_capabilities & CLIENT_SECURE_CONNECTION ?
*passwd++ : strlen(passwd);
db= thd->client_capabilities & CLIENT_CONNECT_WITH_DB ?
db + passwd_len + 1 : 0;
[1]
/* Since 4.1 all database names are stored in utf8 */
if (db)
{
db_buff[copy_and_convert(db_buff, sizeof(db_buff)-1,
system_charset_info,
db, strlen(db),
thd->charset(), &dummy_errors)]= 0;
db= db_buff;
}
--
It can be noticed a check for packet construction is missing here[1].
Just replace the null byte at the end of username
'wisec\0' with any other byte like this 'wisec0'.
What happens?
user is assigned to some part of the packet content, and db is assigned
with some (internal) memory beyond packet_length.
so if we send a specifical packet we'll get an error message like this:
Access denied for user ''@localhost to database 'lqt'
By changing packet lenght (db length) and with a little bit of luck a
malicious user could get sensitive informations such as parts of queries
and or response executed by some previously logged user.
-
The fix:
bugs are fixed in 4.0.27, 4.1.19, 5.0.21, 5.1.10.
You can download them on http://dev.mysql.com/downloads/
=================================================
==Anonymous packet information leakage poc :
my_anon_db_leak.c
Compile with:
gcc my_anon_db_leak.c -o my_anon_db_leak
usage:
my_anon_db_leak [-s path/to/socket] [-h hostname_or_ip]
[-p port_num] [-n db_len]
Example
$ my_anon_db_leak -s /tmp/mysql.sock -n 20
Regards,
Stefano
--
......---oOOo--------oOOo---......
Stefano Di Paola
Software Engineer
Email: stefano.dipaola_at_wisec.it
Email: stefano.dipaola1_at_tin.it
Web: www.wisec.it
..................................