Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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:

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.



I would imagine you have to try a different password each time.


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.


The password is combined with a random value on each attempt, the hash will change each time.


memcmp will probably return always the same value for the same parameters, which may not trigger the error. Trying different values may yield a value whose mod is 0.


It works exactly as written on my completely up to date 64 bit Ubuntu 12.04 laptop running "5.5.22-0ubuntu1"




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: