o-----------ooO--(- Important  Message -)--Ooo------------o
|                                                         |
| SAVE BANDWITH, SPACE, TIME & MONEY, REPLY WITH PRUDENCE.|
|                                                         |
o----=[ Penguin @ My - Linux ([EMAIL PROTECTED]) ]=----o




-------- Original Message --------
Subject: [UNIX] MySQL password handling problem
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]

The following security advisory is sent to the securiteam mailing list, and can be 
found at the
SecuriTeam web site: http://www.securiteam.com


          MySQL password handling problem
--------------------------------------------------------------------------------


SUMMARY

Anyone with access to a MySQL database connection and GRANT privilege for 
any database or table in it, can change any MySQL password they wish, 
including the superuser's.

DETAILS

Vulnerable systems:
MySQL 3.22.27
MySQL 3.22.29
MySQL 3.23.8
(And probably all MySQL versions since 3.22.11)

If the malicious user has access to run processes on the machine where 
MySQL is running, that user can hijack the entire database. If the 
attacker does not have such access, it is still possible to perform a DoS 
attack on the server by setting the MySQL superuser's password to a random 
string.

The 'test' users installed by MySQL's install scripts have GRANT 
privileges for any database whose name begins with 'test', and can 
therefore be used to exploit this bug. The 'test' accounts have no 
passwords set by default, and no restrictions on where connects can come 
from.

This makes all default-configured MySQL very vulnerable (anyone on the net 
can change the MySQL superuser password!). Be aware, however, that any 
user with a GRANT privilege (no matter on which database) in your MySQL 
installation can exploit this bug. You may be vulnerable even if you've 
removed the 'test' users.

Temporary workaround:
1) Revoke all GRANT privileges from all users in your MySQL system except 
root@localhost. This includes GRANTs in the mysql.db table.

2) Confirm that your root@localhost password has not been altered.

Details:
The bug is that the GRANT statement does not properly check privileges 
when you give it an IDENTIFIED BY-clause. You can therefore GRANT someone 
(including the MySQL superuser) a privilege you yourself possess, and set 
her/his password at the same time using IDENTIFIED BY.

Which privilege you pass on does not matter. It is the side effect of the 
IDENTIFIED BY that does the magic. This can be exploited regardless of 
your other permissions. You only need the GRANT privilege for any table or 
database to exploit this bug.

For someone having login access to the machine running MySQL, hijacking 
the database is trivial once the MySQL superuser password has been changed 
using the above method. For someone without login access, changing the 
superuser password can be a simple way of performing a DoS attack against 
the server (not to mention the possibility of extortion).

In the default setup, MySQL prohibits access to the superuser account from 
any other hosts than localhost. Sites that allow superusers to connect 
from the net may be vulnerable to hijacking from malicious users without 
local access.

Since the password-less 'test'-accounts created by MySQL installation 
scripts have GRANT privileges for any database whose name begins with 
'test', they can be used to exploit this bug.

Source patch:

*** /my/monty/master/mysql-3.23.8-alpha/sql/sql_parse.cc        Fri Dec 31 
13:53:03 1999
--- ./sql_parse.cc      Mon Jan 10 21:53:59 2000
***************
*** 1222,1227 ****
--- 1222,1246 ----
                      tables ? &tables->grant.privilege : 0,
                      tables ? 0 : 1))
         goto error;
+
+      /* Check that the user isn't trying to change a password for
    another
+       user if he doesn't have UPDATE privilege to the MySQL database
    */
+
+      List_iterator <LEX_USER> user_list(lex->users_list);
+      LEX_USER *user;
+      while ((user=user_list++))
+      {
+        if (user->password.str &&
+          (strcmp(thd->user,user->user.str) ||
+           user->host.str && my_strcasecmp(user->host.str,
+                                           thd->host ? thd->host :
thd->ip)))
+        {
+        if (check_access(thd, UPDATE_ACL, "mysql",0,1))
+          goto error;
+        break;                                 // We are allowed to
do changes
+        }
+      }
+
       if (tables)
       {
         if (grant_option && check_grant(thd,


ADDITIONAL INFORMATION

The information was provided by:  <mailto:[EMAIL PROTECTED]> Viktor 
Fougstedt.



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


This bulletin is sent to members of the SecuriTeam mailing list. 
To unsubscribe from the list, send mail with an empty subject line and body to:
[EMAIL PROTECTED] 
In order to subscribe to the mailing list, simply forward this email to:
[EMAIL PROTECTED] 


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

DISCLAIMER: 
The information in this bulletin is provided "AS IS" without warranty of any kind. 
In no event shall we be liable for any damages whatsoever including direct, indirect, 
incidental,
consequential, loss of business profits or special damages.
-
Disclaimer : http://users.my-linux.org/disclaimer.html

Reply via email to