yggtorrentz | torrents | home page
THP Wisec USH DigitalBullets TheHackersPlace network
The WIse SECurity
.italian
.english
Wisec Home SecSearch Projects Papers Security Thoughts
 
News Search on Wisec
Google

MySQL Anonymous Login Handshake - Information Leakage.

Title:

MySQL Anonymous Login Handshake - Information Leakage.

Author:

Stefano Di Paola

Vulnerable:

MySQL <= 4.0.26, 4.1.18,5.0.20

Type of Vulnerability:

Local/Remote

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

Fix :

Update to 4.0.27, 4.1.19, 5.0.21, 5.1.10 versions.

Download the Proof of Concept

my_anon_db_leak.c

Description

~.oOOo. Anonymous Login Handshake .oOOo.~
=========================================

MySQL Server (<= 4.0.26, 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.0.26, 4.1.18, 5.0.20
Type of Vulnerability: Local/Remote - input validation
Tested On :  Debian 3.1 - IA32.
Vendor Status: Notified on March 2005
Fixed: Update to 4.0.27, 4.1.19, 5.0.21, 5.1.10 versions.

A Proof of Concept is Attached for all these issues.
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 arbitrary 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
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].
 
it is sufficent to 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.

-

The fix:

bugs are fixed in 4.0.27, 4.1.19, 5.0.21, 5.1.10.

=================================================

==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 unix_socket [-s path/to/socket] [-h hostname_or_ip]
[-p port_num] [-n db_len]





Solution

Mysql released a patch. Update to 4.0.27, 4.1.19, 5.0.21, 5.1.10 MySQL versions. Download them to fix the issue. Thanks to MySQL Company people, they where very kind and professional.

Disclaimer

In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk.

Florence, 2nd of May 2006

Wisec is brought to you by...

Wisec is written and mantained by Stefano Di Paola.

Wisec uses open standards, including XHTML, CSS2, and XML-RPC.

All Rights Reserved 2004
All hosted messages and metadata are owned by their respective authors.