tags 330164 unreproducible thanks hi christian, joey, martin, et al:
after having spent more time looking at this bug, i'm once again unconvinced that there is a problem. the original poster in the ubuntu bts said: > I launched the attached exploit both against 4.0.24 and 4.1.14 and in both > cases > I was able to gain access to db. > > [EMAIL PROTECTED]:~$ perl ./mysql-auth-bypass.pl antani localhost > Using default MySQL port (3306) > Received greeting: > 00000000 54 00 00 00 FF 6A 04 23 48 59 30 30 30 48 6F 73 > 00000010 74 20 27 6C 6F 63 61 6C 68 6F 73 74 2E 6C 6F 63 > 00000020 61 6C 64 6F 6D 61 69 6E 27 20 69 73 20 6E 6F 74 > 00000030 20 61 6C 6C 6F 77 65 64 20 74 6F 20 63 6F 6E 6E > 00000040 65 63 74 20 74 6F 20 74 68 69 73 20 4D 79 53 51 > 00000050 4C 20 73 65 72 76 65 72 > > Sending caps packet: > 00000000 3C 00 00 01 85 A6 03 00 00 00 00 01 08 00 00 00 > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00000020 00 00 00 00 61 6E 74 61 6E 69 00 14 00 00 00 00 > 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00000040 > > Received reply: > 00000000 > Received OK reply, authentication successful!! notice that the reply is empty. this is because the mysql server has already closed the connection and the read call on the socket in the perl script returns 0 bytes. i verified this by packetdumping the conversation. also, it's worth noting that the "greeting" packet contains an "access denied from this host" message. thus it did not succeed, but the exploit's result-checking leaves something to be desired (guess what checking for a zero byte does when checking an empty variable in perl). if i make an exception to allow connections from an intruding host, i get: mini-me[~]00:37:24$ ./mysql-auth-bypass.pl root copelandia Using default MySQL port (3306) Received greeting: 00000000 3B 00 00 00 0A 34 2E 30 2E 32 34 5F 44 65 62 69 00000010 61 6E 2D 31 30 73 61 72 67 65 31 2D 6C 6F 67 00 00000020 12 00 00 00 21 4B 37 72 59 46 35 72 00 2C 20 08 00000030 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sending caps packet: 00000000 3A 00 00 01 85 A6 03 00 00 00 00 01 08 00 00 00 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000020 00 00 00 00 72 6F 6F 74 00 14 00 00 00 00 00 00 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Received reply: 00000000 3B 00 00 02 FF 15 04 41 63 63 65 73 73 20 64 65 00000010 6E 69 65 64 20 66 6F 72 20 75 73 65 72 3A 20 27 00000020 40 31 30 2E 30 2E 30 2E 31 27 20 28 55 73 69 6E 00000030 67 20 70 61 73 73 77 6F 72 64 3A 20 4E 4F 29 Authentication failed! notice that the reply packet actually has data in it, and the hexdump contains an ascii "Access denied" message. Also note that this is with an unpatched sarge1 version of a supposedly vulnerable version of mysql-server. however, i'm not convinced that there isn't a problem either. when looking at the packet dump, it appears as though the packet is not correctly formed, and the username/password are in the wrong location in the packet. trying to "adjust" things in the packet does not yield results, but it could be that my adjusting breaks something else in the process. however, the patch /does/ apply (granted with some fuzz on the woody version). the question is whether the path of execution in the code can lead to the same vulnerability, or whether this vector os not possible in these two versions of mysql. given that we don't have a working exploit though, i'm not sure it is. *but*, just in case someone would like to try a patched vs. unpatched test, i've made the "fixes" for woody and sarge available: http://people.debian.org/~seanius/mysql/woody/mysql_3.23.49-8.15.diff.gz http://people.debian.org/~seanius/mysql/sarge/mysql-dfsg_4.0.24-10sarge2.diff.gz but as i said, i once again remain to be convinced, and don't care to waste any more of my time on the matter unless someone can once again swing me over to believing it is an issue again. sean ps - christian: the sarge-4.0 svn branch contains these plus the recent security update merged, but i haven't done so with the woody branch.
signature.asc
Description: Digital signature
