Fuer alle welche die BUGTRAQ nicht lesen (was Remote access vulnerability in all MySQL server versions)

["Mariano Glas" <glas_(at)_orgaline.de>]

Mfg Mariano Glas

-----Ursprüngliche Nachricht-----
Von: Robert van der Meulen <rvdm_(at)_CISTRON.NL>
An: <BUGTRAQ_(at)_SECURITYFOCUS.COM>
Gesendet: Dienstag, 8. Februar 2000 20:03
Betreff: Remote access vulnerability in all MySQL server versions


> Hi,
>
> Below you find a security advisory i wrote concerning a vulnerability
found in
> all (known to me) mysql server versions, including the latest one.
> As mysql is a widely used sql platform, i strongly advise everyone using
it
> to read it, and fix where appropriate.
> This email has been bcc'd to the mysql bug list, and other appropriate
parties.
>
> Greets,
> Robert van der Meulen/Emphyrio
>
>
> .Introduction.
>
> There exists a vulnerability in the password checking routines in the
latest
> versions of the MySQL server, that allows any user on a host that is
allowed
> to connect to the server, to skip password authentication, and access
databases.
> For the exploit to work, a valid username for the mysql server is needed,
and
> this username must have access to the database server, when connecting
from
> the attacking host.
>
>
> .Vulnerable Systems.
>
> All systems running 3.22.26a and up (tested).
> Probably all systems running lower versions as well (not tested, not
reviewed).
> All versions are vulnerable on all platforms.
>
>
> .A snippet of code from the mysql code, explaining password authentication
**
>
> >From mysql-3.22.26a/sql/password.c:
> /* password checking routines */
>
/***************************************************************************
**
>   The main idea is that no password are sent between client & server on
>   connection and that no password are saved in mysql in a decodable form.
>
>   On connection a random string is generated and sent to the client.
>   The client generates a new string with a random generator inited with
>   the hash values from the password and the sent string.
>   This 'check' string is sent to the server where it is compared with
>   a string generated from the stored hash_value of the password and the
>   random string.
>
> <cut>
>
****************************************************************************
*/
>
>
> .More code, and vulnerability explanation.
>
> The problem is, that in the comparison between the 'check' string, and the
> string generated from the hash_value of the password and the random
string,
> the following code is used (from mysql-3.22.26a/sql/password.c):
>
>   while (*scrambled)
>   {
>     if (*scrambled++ != (char) (*to++ ^ extra))
>       return 1;                                 /* Wrong password */
>   }
>
> 'scrambled' represents the 'check' value, and (*to++ ^ extra) walks trough
the
> hash_value.
> Suppose a client would send a _single_ character to the server as the
'check'
> string.
> Of course the server should notice the check string is not the same length
as
> the check string needed, and give a password error.
> Because no such checks are done, when a check string of length 1 is passed
to
> the server, only one character is compared.
> So the only thing that remains to know if we want to peek in someone's
MySQL
> database, is a technique to find out the first character of the
server-side
> check string.
>
> The string that's used for the comparison is generated using some random
data,
> so two following authenticate-actions will probably use different
check-strings.
> After looking at the algorithm, generating the check string, it becomes
clear
> that there are actually only 32 possibilities for each character.
>
> In practice, this means that if you connect, sending one single character
as
> the check string, you will be in in about 32 tries maximum.
>
>
> .Impact.
>
> Hosts in the access list (by default any host, on a lot of distributions
and
> servers) can connect to the MySQL server, without a password, and access
> (often sensitive) data _as long as the attacker has a valid username for
the
> database server_.
> This vulnerability also incorporates a MySQL DoS attack, as the attacker
can
> shutdown database servers and delete data, if she logs in with the MySQL
> management account.
>
>
> .Exploit information.
>
> I have an exploit available, but to defer script kiddies i will not
release
> it (yet).  Do not ask me for it.
> If above explanation is understood, an exploit should be easy enough...
>
>
> .Fix information.
>
> Change the routine 'check_scramble' in mysql-3.22.26a/sql/password.c to do
a
> length check, _before_ starting the compare.
> This should be as easy as inserting the following just above the
> while (*scrambled) loop:
>
> if (strlen(scrambled)!=strlen(to)) {
> return 1;
> }
>
> WARNING: This is NOT an official fix. You can use this as a temporary
solution
> to the problem.
> Please check the official mysql site (www.mysql.org) for a fix.
>
>
> .Commentary.
>
> I think this exploit should not be a very scary thing to people that know
> how to secure their servers.
> In practice, there's almost never a need to allow the whole world to
connect
> to your SQL server, so that part of the deal should be taken care of.
> As long as your MySQL ACL is secure, this problem doesn't really occur
(unless
> your database server doubles as a shell server).
>
> We have also located several other security bugs in mysql server/client.
These
> bugs can only be exploited by users who have a valid username and
password.
> We will send these to the mysql maintainers, and hope they'll come
> with a fix soon.
>
> Yours,
>         Robert van der Meulen/Emphyrio (rvdm_(at)_cistron.nl)
>         Willem Pinckaers (dvorak_(at)_synnergy.net)
>
>
> --
>
> |      rvdm_(at)_cistron.nl - Cistron Internet Services - www.cistron.nl
|
> |          php3/c/perl/html/c++/sed/awk/linux/sql/cgi/security
|
> |         My statements are mine, and not necessarily cistron's.
|
>


---
*** Abmelden von dieser Mailingliste funktioniert per E-Mail
*** an mysql-de-request_(at)_lists.4t2.com mit Betreff/Subject: unsubscribe