Fuer alle welche die BUGTRAQ nicht lesen (was Remote access vulnerabilit
Archiv Mailingliste mysql-de

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Mfg Mariano Glas

-----Ursprüngliche Nachricht-----
Von: Robert van der Meulen <rvdm_(at)_CISTRON.NL>
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
> to read it, and fix where appropriate.
> This email has been bcc'd to the mysql bug list, and other appropriate
> Greets,
> Robert van der Meulen/Emphyrio
> .Introduction.
> There exists a vulnerability in the password checking routines in the
> versions of the MySQL server, that allows any user on a host that is
> to connect to the server, to skip password authentication, and access
> For the exploit to work, a valid username for the mysql server is needed,
> this username must have access to the database server, when connecting
> 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
> 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
> 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
> hash_value.
> Suppose a client would send a _single_ character to the server as the
> string.
> Of course the server should notice the check string is not the same length
> the check string needed, and give a password error.
> Because no such checks are done, when a check string of length 1 is passed
> the server, only one character is compared.
> So the only thing that remains to know if we want to peek in someone's
> database, is a technique to find out the first character of the
> check string.
> The string that's used for the comparison is generated using some random
> so two following authenticate-actions will probably use different
> After looking at the algorithm, generating the check string, it becomes
> that there are actually only 32 possibilities for each character.
> In practice, this means that if you connect, sending one single character
> 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
> 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
> database server_.
> This vulnerability also incorporates a MySQL DoS attack, as the attacker
> 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
> 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
> 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
> to the problem.
> Please check the official mysql site ( 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
> 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
> your database server doubles as a shell server).
> We have also located several other security bugs in mysql server/client.
> bugs can only be exploited by users who have a valid username and
> 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)
>         Willem Pinckaers (dvorak_(at)
> --
> |      rvdm_(at) - Cistron Internet Services -
> |          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) mit Betreff/Subject: unsubscribe

Home | Main Index | Thread Index

php::bar PHP Wiki   -   Listenarchive