Name: MySQL Authentication Bypass / Buffer Overflow Systems Affected: MySQL 4.1 prior to 4.1.3, and MySQL 5.0. Severity: High Vendor URL: http://www.mysql.com Author: Chris Anley [ chris ngssoftware com ] Date of Advisory: 1st July 2004
Whitepaper **********
We have written a paper that accompanies this advisory. The paper provides details of various MySQL lockdown techniques, and a review of common attacks on MySQL, including SQL injection. The paper can be found at
"The MySQL database server is the world's most popular open source database." [www.mysql.com].
This advisory details a bug that allows a remote user to entirely bypass the MySQL password authentication mechanism, allowing them to authenticate as a MySQL user without knowing that user's password. Using a similar method, a stack buffer used in the authentication mechanism can be overflowed, though exploitation of the overflow is not straightforward.
Details *******
MySQL 4.1 Authentication Bypass
By submitting a carefully crafted authentication packet, it is possible for an attacker to bypass password authentication in MySQL 4.1.
From check_connection (sql_parse.cpp), line ~837:
/* Old clients send null-terminated string as password; new clients send the size (1 byte) + string (not null-terminated). Hence in case of empty password both send '\0'. */ uint passwd_len= thd->client_capabilities & CLIENT_SECURE_CONNECTION ? *passwd++ : strlen(passwd);
Provided 0x8000 is specified in the client capabilities flags, the use can specify the passwd_len field of their choice. For this attack, we will choose 0x14 (20) which is the expected SHA1 hash length.
Several checks are now carried out to ensure that the user is authenticating from a host that is permitted to connect. Provided these checks are passed, we reach:
/* check password: it should be empty or valid */ if (passwd_len == acl_user_tmp->salt_len) { if (acl_user_tmp->salt_len == 0 || acl_user_tmp->salt_len == SCRAMBLE_LENGTH && check_scramble(passwd, thd->scramble, acl_user_tmp->salt) == 0 || check_scramble_323(passwd, thd->scramble, (ulong *) acl_user_tmp->salt) == 0) { acl_user= acl_user_tmp; res= 0; } }
the check_scramble function fails, but within the check_scramble_323 function we see:
At this point, the user has specified a 'scrambled' string that is as long as they wish. In the case of the straightforward authentication bypass, this is a zero-length string. The final loop compares each character in the 'scrambled' string against the string that mysql knows is the correct response, until there are no more characters in 'scrambled'. Since there are no characters *at all* in 'scrambled', the function returns '0' immediately, allowing the user to authenticate with a zero-length string.
This bug is relatively easy to exploit, although it is necessary to write a custom MySQL client in order to do so.
In addition to the zero-length string authentication bypass, the stack-based buffer 'buff' can be overflowed by a long 'scramble' string. The buffer is overflowed with characters output from my_rnd(), a pseudo random number generator. The characters are in the range 0x40..0x5f. On some platforms, arbitrary code execution is possible, though the exploit is complex and requires either brute force, or knowledge of at least one password hash.
Fix Information and workarounds *******************************
MySQL AB were contacted on the 1st of June 2004 and the patch for this bug was present in the source code by the 2nd of June. Since MySQL prefer users to install via pre-built binary packages, NGS have delayed the release of this advisory until appropriate 'patch' packages were available.
MySQL AB have fixed this bug in version 4.1.3, and the most recent builds of version 5.0.
In addition to patching, various workarounds are possible for this bug. The attacker must know or be able to guess the name of a user in order for this attack to work, so renaming the default MySQL 'root' account is a reasonable precaution. Also, the account in question must be accessible from the attacker's host, so applying ip-address based login restrictions will also mitigate this bug.
A check for this vulnerability has been added to Typhon III, NGSSoftware's advanced vulnerability assessment scanner. For more information please visit the NGSSoftware website at http://www.ngssoftware.com/
About NGSSoftware *****************
NGSSoftware design, research and develop intelligent, advanced application security assessment scanners. Based in the United Kingdom, NGSSoftware have offices in the South of London and the East Coast of Scotland. NGSSoftware's sister company NGSConsulting, offers best of breed security consulting services, specializing in application, host and network security assessments.
yet none of them work, with any luck... either this isnt vulnerable, or i may need to send another null packet since i just noticed it does "login <\x00\> pass"
ill update in a few
in conclusion... i have sent
CODE
my $body = "\0\0\x01\x85\x00\00\00\00". join "\0","test","",""; my $login_message = chr(length($body)-3). $body; $mysql->send($login_message, 0);
which should initially bypass it... it sends test, spacer, then null pass. packet log:
as you can see the last x00 is a null character...
so its possible 4.0.20 isnt vulnerable.... its running RH Fedora Core 2 by the way.
brOmstar
Jul 6 2004, 04:45 PM
only 4.1.x should be vuln i think
QUOTE
Details *******
MySQL 4.1 Authentication Bypass
By submitting a carefully crafted authentication packet, it is possible for an attacker to bypass password authentication in MySQL 4.1.
twistedps
Jul 6 2004, 05:48 PM
yeah, i noticed that, but i thought possibly versions before that would be vulnerable too *shrugs*, guess not.
edit: looked over the code for 4.0.x its completely different concerning the authentication scheme... so the null login wont work, but im not sure about the other vulnerability, but from what i can tell its 4.1.x only also...
this is kinda dissapointment considering that 4.1.x is still in beta, and 4.0.x is the main development build. but maybe there is still some 4.1.x servers out there
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
