CVE-2004-0627: The check_scramble_323 function in MySQL 4.1.x before 4.1.3, and 5.0, allows remote attackers to bypass authentication via a zero-length scrambled string. http://archives.neohapsis.com/archives/vulnwatch/2004-q3/0001.html http://marc.theaimsgroup.com/?l=bugtraq&m=108904917528205&w=2 http://www.kb.cert.org/vuls/id/184030
Created attachment 476481 [details] Demo exploit, for posterity. This exploit is broken, and since it's needed to show why it's broken, I'm adding it. I imagine it will be lost to the sands of time eventually. Source: http://www.securityfocus.com/bid/10654/exploit
The below analysis was written by Tom Lane. The CVE entry links to a detailed explanation of the bug at http://archives.neohapsis.com/archives/vulnwatch/2004-q3/0001.html which includes the faulty source code from mysql 4.1: to=buff; for (pos=scrambled ; *pos ; pos++) *to++=(char) (floor(my_rnd(&rand_st)*31)+64); In mysql 5.0.77 the same part of check_scramble_323() looks like to=buff; DBUG_ASSERT(sizeof(buff) > SCRAMBLE_LENGTH_323); for (pos=scrambled ; *pos && to < buff+sizeof(buff) ; pos++) *to++=(char) (floor(my_rnd(&rand_st)*31)+64); if (pos-scrambled != SCRAMBLE_LENGTH_323) return 1; So this has been hardened both by guarding against too long password (which formerly would overrun the local buff[] variable) and by checking for the exact expected length, which ought to stop the described attack. The latter change is what you fingered as being the relevant 5.0 commit; I guess they noticed the overrun risk later. So CVE-2004-0627 is definitely fixed in 5.0.77, and presumably ever since 5.0.1. I also tried the exploit script at http://www.securityfocus.com/bid/10654/exploit and concluded that it is broken. Tracing the server's behavior with gdb, I see that what actually happens is that the server thinks the client has sent a new-style password, but the server knows it has an old-style password (as a result of our defaulting to old_password=1 in /etc/my.cnf). It sends a challenge packet to the client asking for the password to be resent in old style (see send_old_password_request). The exploit script is misinterpreting that packet as a success response. So far as I can tell, check_scramble_323() is never reached at all in this test.
Created attachment 476540 [details] Authentication bypass fix The fix for the authentication bypass issue mentioned in the previous comment. http://bazaar.launchpad.net/~mysql/mysql-server/mysql-5.0/revision/1616.440.16 http://bazaar.launchpad.net/~mysql/mysql-server/mysql-4.1/revision/1843.6.16
The buffer overflow mentioned in the report and previous comments was assigned CVE-2004-0628: Stack-based buffer overflow in MySQL 4.1.x before 4.1.3, and 5.0, allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a long scramble string. http://archives.neohapsis.com/archives/vulnwatch/2004-q3/0001.html http://marc.theaimsgroup.com/?l=bugtraq&m=108904917528205&w=2 http://xforce.iss.net/xforce/xfdb/16612 http://www.kb.cert.org/vuls/id/645326 It seems this overflow was only fixed few months later: http://bugs.mysql.com/bug.php?id=7187 http://bazaar.launchpad.net/~mysql/mysql-server/mysql-5.0/revision/1616.1357.22 http://bazaar.launchpad.net/~mysql/mysql-server/mysql-4.1/revision/2055.209.22
Created attachment 476542 [details] Buffer overflow fix
Bit of a history note - check_scramble_323 was apparently based on check_scramble from 3.x versions. MySQL 3.x had rather similar issue in 2000 - see CVE-2000-0148. It was addressed by adding password length check earlier in the code, rather than in check_scramble directly.
Statement: Not vulnerable. This issue did not affect the versions of MySQL as shipped with Red Hat Enterprise Linux 4, 5, or 6.