mySQLgame[1] demonstrates that domain logic can be successfully implemented within a publicly accessible database[2]. It would be better to reword your statement to:
Minimise the attack surface by preventing unnecessary access
There are times where public access to a database server make perfect sense. It is the reason why database servers implement TLS client certificate verification, Role Based Access Control (RBAC) and other security features which a typical application (with domain logic at the application layer) has no hope of implementing correctly.
In any case, the typical web app deployed by HN readers has no business having an exposed MySQL port.
Cheapest? SSH tunnel or openvpn point to point link.
If you do need your mysql to be exposed to the internet you can use bind_address=x.x.x.x or some kind of firewall.
https://github.com/rapid7/metasploit-framework/blob/master/m...
Thus began years of efforts on our part of security fixes, which I would not have started except that I had customers to support.
Ubuntu always ship fucked up, broken, shitty MySQL versions.
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).
I'm in the process of binning it all and moving to Debian which is actually trustworthy...
How do you know, how the Ubuntu devs compiled their mysql server?
But, that is just my single VM instance and I would assume HD Moore knows what he is doing.
This is why real C programmers use int as their bool type. :)
It has the same problem if a wider type (e.g. long) is assigned to it. Use _Bool instead.
return 0 == memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE)
I mean, as I read it, the function returns true if they don't match?
I thought at first it might be because I do not have a root password (it's a VM) so trying to use any password at all returns a failure before the faulty code is reached. Then I tried to login as debian-sys-maint and some other users that do have passwords, and it still did not work.
(Again, this is just an unconfirmed theory.)
Also, the associated bug report: https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/101....
This is a slicehost box, so I'm assuming that can be extrapolated to mean that anyone using ubuntu on slicehost is probably safe.
Debian lenny 32-bit 5.0.51a-24+lenny5
Debian lenny 64-bit 5.0.51a-24+lenny5
Debian lenny 64-bit 5.1.51-1-log
Debian squeeze 64-bit 5.1.49-3-log
Debian squeeze 32-bit 5.1.61-0+squeeze1
Debian squeeze 64-bit 5.1.61-0+squeeze1
Ubuntu lucid 64-bit 5.1.62-0ubuntu0.10.04.1
So I'm not inclined to think it's as bad as made out by the simple exploit above.
That's two months ago. Looking at the changelog (http://dev.mysql.com/doc/refman/5.1/en/news-5-1-63.html), they piled in a bunch of other changes like "use less disk space". This should have gone out pronto. I feel it's not the kind of thing you sit on until your next quarterly release is scheduled.
[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.]
What ever happened to public disclosure as soon as a patch is released?
I have been bit twice by problems relating to difficulties getting security fixes/announcements out in time. In my defence I was trying to patch a difficult codebase and this just took a long time. For example, there was a full SQL injection audit that took us two months to complete early on, and there was an issue of XSRF vulnerabilities which could not be effectively patched in a production release.
But waiting a month to announce the security issue after the release was out strikes me as hard to justify.
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.
See https://lists.ubuntu.com/archives/ubuntu-server/2012-Februar... and https://lists.ubuntu.com/archives/ubuntu-server/2012-Februar... for details.
This is a serious vulnerability. Especially since the latest ubuntu seems to be affected(I'm on mint 13, and it is)
See Ready shodanhq query for latest mysql version:
http://www.shodanhq.com/search?q=port%3A3306+5.5.22-0ubuntu1
Why 1/256?
Via HDMOORE on twitter
Here's a guide for limiting access to it by IP address via the apache config for Ubuntu users:
http://mixeduperic.com/ubuntu/how-to-restrict-phpmyadmin-ip-...
I am sad to say it worked on my Ubuntu server :(
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).