Earlier quoted context omitted.
except that they try to optimize randomness in security libraries every now and then.
Any more details? Not had any problems on that side of things yet.
Security vulnerability in MySQL ubuntu
61–70 of 116 posts
Re: Security vulnerability in MySQL ubuntu
#62Re: Security vulnerability in MySQL ubuntu
#63Just 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. This is a slicehost box, so I'm assuming that can be extrapolated to mean that anyone using ubuntu on slicehost is probably safe.
That's a horrid assumption, is verifiably wrong and what in God's name are you doing on Hardy? You just screamed "ignore me" three times in two sentences.
Re: Security vulnerability in MySQL ubuntu
#64This 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. Attackers should never, ever be able to connect directly to your MySQL database directly . If you can connect to your MySQL instance directly from your Macbook in your living room, fix it right now .
"Never" ... You are aware of the existence and mass use of shared web hosting systems right?
Right. By this logic MySQL doesn't need authentication, never mind privileges.
Re: Security vulnerability in MySQL ubuntu
#65Re: Security vulnerability in MySQL ubuntu
#66Earlier quoted context omitted.
―Attackers should never, ever be able to connect directly to your MySQL database directly. 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 data…
Either use iptables to lock it down to a particular IP or set of IPs. Or setup ssh tunnelling to expose a remote mysql server as a local port. You should assume mysql is insecure and needs protecting.
You're just swapping one exposed service for another in that case. Ie, OpenSSH instead of MySQL.
On other other hand, I'd trust OpenSSH more than MySQL.
Re: Security vulnerability in MySQL ubuntu
#67I'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: 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 Deb…
It works exactly as written on my completely up to date 64 bit Ubuntu 12.04 laptop running "5.5.22-0ubuntu1"
Re: Security vulnerability in MySQL ubuntu
#68Earlier quoted context omitted.
Why would you imagine that? The bug is that what password you provide doesn't matter.
That wasn't how I read it. It sounds like they were casting the result of a memcmp to a char. A char only has a range of -128 to 127. The resulting overflow means that an arbitrary password hash has a 1/255 chance of landing on 0, but you still have to try a bunch to hit one.
This is incorrect. You do not need to try a different password each time.
Re: Security vulnerability in MySQL ubuntu
#69"Because the protocol uses random strings, the probability of hitting this bug is about 1/256." Why 1/256?
Because when the return value is truncated to a char, the last two bytes in the int would have to be 0x00, which is 1/256 assuming the return value is a completley random int.
Re: Security vulnerability in MySQL ubuntu
#70Earlier quoted context omitted.
Either use iptables to lock it down to a particular IP or set of IPs. Or setup ssh tunnelling to expose a remote mysql server as a local port. You should assume mysql is insecure and needs protecting.
You're just swapping one exposed service for another in that case. Ie, OpenSSH instead of MySQL. On other other hand, I'd trust OpenSSH more than MySQL.
Well, you're reducing the exposed services from two (mysql + ssh), to one (ssh). Which is always a good idea.
Also agreed. I'd trust OpenSSH to do security better than MySQL.