Bug 674431 (CVE-2004-0627, CVE-2004-0628)

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.