MariaDB and MySQL Authentication Bypass Exploit

← Back to Stories (view on slashdot.org)

MariaDB and MySQL Authentication Bypass Exploit

Posted by samzenpus on Monday June 11, 2012 @05:20AM from the protect-ya-neck dept.

JohnBert writes "A security bug in MariaDB and MySQL has been revealed, allowing a known username and password to access the master user table of a MySQL server and dump it into a locally-stored file. By using a tool like John the Ripper, this file can be easily cracked to reveal text passwords that can provide further access. By committing a threaded brute-force module that abuses the authentication bypass flaw to automatically dump the password database, you can access the database using the cracked password hashes even if the authentication bypass vulnerability is fixed."

73 comments

Min score:

Reason:

Sort:

holy motherfucking cheetah by gl4ss · 2012-06-11 05:23 · Score: 4, Insightful

"An attacker who knows a correct username (usually the ubiquitous "root") can easily connect using a random password by repeating connection attempts.
"~300 attempts takes only a fraction of second, so basically account password protection is as good as nonexistent," wrote Golubchik."
I guess the db shouldn't answer to any requests outside from known address space.. but still..

--
world was created 5 seconds before this post as it is.
1. Re:holy motherfucking cheetah by Anonymous Coward · 2012-06-11 05:28 · Score: 5, Insightful
  
  And that is why we use fail2ban.
2. Re:holy motherfucking cheetah by WrongSizeGlass · 2012-06-11 05:32 · Score: 2
  
  a 1/256 chance of getting in when using a valid username and invalid email? I don't like those odds.
3. Re:holy motherfucking cheetah by WrongSizeGlass · 2012-06-11 05:36 · Score: 2
  
  a 1/256 chance of getting in when using a valid username and invalid email? I don't like those odds.
  Email? WTF? That should be password.
4. Re:holy motherfucking cheetah by gl4ss · 2012-06-11 05:44 · Score: 1
  
  And that is why we use fail2ban.
  well, you'd still only need ~300 ip's to launch the attack from.
  with those odds, I'm thinking that many people who have bruteforced have thought themselfs as extremely lucky when they werent..
  
  --
  world was created 5 seconds before this post as it is.
5. Re:holy motherfucking cheetah by ArcherB · 2012-06-11 05:52 · Score: 1
  
  And that is why we use fail2ban.
  well, you'd still only need ~300 ip's to launch the attack from.
  with those odds, I'm thinking that many people who have bruteforced have thought themselfs as extremely lucky when they werent..
  That's ~300 IP's per fraction of a second.
  Good luck with that.
  
  --
  There is no "I disagree" mod for a reason. Flamebait, Troll, and Overrated are not substitutes.
6. Re:holy motherfucking cheetah by rtfa-troll · 2012-06-11 06:05 · Score: 1
  
  That's ~300 IP's per fraction of a second.
  Good luck with that.
  Can you say "botnet". Hmm.. I wonder who would benefit from being able to get a few thousands of extra hosts. Most of the big ones would probably never even need to use the same IP range more than twice.
  
  --
  =~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
7. Re:holy motherfucking cheetah by joostje · 2012-06-11 06:09 · Score: 1
  
  That's ~300 IP's per fraction of a second.
  Good luck with that.
  You only need ~256 login attempts to get in. So, yes, you'd only need ~256 IP's to have a 63% chance of gaining root access (1-(255/256)**256).
8. Re:holy motherfucking cheetah by SteveAyre · 2012-06-11 06:25 · Score: 4, Informative
  
  They say you can get in by making 300 connection attempts, which can be done within a fraction of a second. Which is true.
  They don't say that you have to do it within a fraction of a second.
  The memcmp function has a 1/256 chance of returning the required value that makes it treat any password as the correct password - there's no link between the connection attempts, each time you try to connect you have the same 1/256 chance. You could space the attempts out over seveal minutes, hours or days if you wanted to - it'd just slow down the time it'd take you to get in (and make it more likely they've patched their systems before you get in).
  Practically, this is slightly less newsworthy than it sounds. Yes the bug exists and yes it's serious, but it also depends on which memcmp version you're using on whether you're actually affected. The gcc builtin ones aren't affected or the libc ones, the glibc one is. That means whether it's exploitable depends on how your server was compiled. And it appears that the official versions from mysql.com aren't affected, and testing my debian systems today neither are they (but they're nicely firewalled anyway, just in case). Source: http://seclists.org/oss-sec/2012/q2/493
9. Re:holy motherfucking cheetah by Anonymous Coward · 2012-06-11 07:09 · Score: 0
  
  Ah, glibc. The reason I use FreeBSD instead of Linux.
  Drepper is an idiot.
10. Re:holy motherfucking cheetah by hairyfeet · 2012-06-11 07:22 · Score: 5, Informative
  
  Oh c'mon now, where else can you get such nasty venom? You just gots to love stuff like this where he says ARM is nothing but "embedded crap" How can you NOT like such an arrogant little self important shit? hell he reminds me of little Mickey 500 accounts here, all he needs to do is add "You are pathetic" at the end of each post and he'd have it down pat!
  
  --
  ACs don't waste your time replying, your posts are never seen by me.
11. Re:holy motherfucking cheetah by leonbloy · 2012-06-11 07:53 · Score: 1
  
  I guess the db shouldn't answer to any requests outside from known address space.. but still..
  There is something called "shared web hosting".
12. Re:holy motherfucking cheetah by geekopus · 2012-06-11 08:07 · Score: 1
  
  Wow. If I hadn't seen that, I would not have believed it. What a jerk!
13. Re:holy motherfucking cheetah by Billly+Gates · 2012-06-11 08:58 · Score: 1
  
  You can rent or purchase 3,000 bots for like $10 on the internet.
  If you are a Russian Mobfia guy who can be profitable with just a few hundred credit card numbers this is a no brainer. You can make millions and only hire some russian CS student for a few hundred dollars to use the bot net to launch 300 ip's and viola! Instant millions.
  This is pretty serious and the profit potential is too large to ignore.
  Putting an authentication server/proxy between the internet and the database is an excellent line of defense. I should say not perfect but unless your a very small mom and pop shop who uses an ISP to host your site on one machine for all databases this is essential and could avoid this kind of attack and you have another machine to check for SQL insertions too.
  
  --
  http://saveie6.com/
14. Re:holy motherfucking cheetah by gl4ss · 2012-06-11 09:57 · Score: 1
  
  I guess the db shouldn't answer to any requests outside from known address space.. but still..
  There is something called "shared web hosting".
  well, shared hosting is for bitches.
  did a first post, titled it "holy motherfucking cheetah" and got +5. I think I'll make that into my new sig
  
  --
  world was created 5 seconds before this post as it is.
15. Re:holy motherfucking cheetah by Anonymous Coward · 2012-06-11 16:46 · Score: 0
  
  Which is completely useless on a shared hosting platform, where the MySQL connections will come from local host.
16. Re:holy motherfucking cheetah by hairyfeet · 2012-06-12 05:23 · Score: 1
  
  Sheeeit, think THAT is bad? Look up "Ulrich Drepper arrogant" into the search engine of your choice and be prepared to see some EPIC douchebaggery! Seriously some of his rants are so epic I'm shocked he just doesn't reply with Goatse as that's pretty obviously what he thinks about those that DARE to disagree with him.
  But you can see why some like Debian would move away, because they simply don't want to deal with such an epic douchenozzle. i have to wonder how many of the other lesser spotlighted FOSS projects have arrogant little all important shits like him running things. After all they aren't doing it for fame or money and we all know how many love to just be absolute assholes when given a little power. But IMHO it shows how the system is broken when someone like Drepper is still allowed to maintain and important piece as Glibc when he is so obviously a massive prick.
  
  --
  ACs don't waste your time replying, your posts are never seen by me.
Could have told us what it is by Anonymous Coward · 2012-06-11 05:25 · Score: 5, Informative

Basically the password comparison routine uses a bad assumption about memcmp. This assumption fails with a probability of about 1 in 256 on some systems. You just use any random password, try a couple hundred times to log in and eventually it works. Yes, it is that bad.
1. Re:Could have told us what it is by Anonymous Coward · 2012-06-11 05:33 · Score: 0
  
  Yeah, I had to read that bit of the article about ten times for it to sink in. No shit they've found exploits in the wild... this sounds like something a ten-year-old would have found after fifteen minutes of penetration testing.
2. Re:Could have told us what it is by Qzukk · 2012-06-11 05:35 · Score: 1
  
  Any idea what that assumption is? The article says typecast error, but what the hell would you cast a signed int to that would be zero when the signed int was nonzero? Even if you cast it to unsigned, you'd still have a nonzero number for negative values.
  
  --
  If I have been able to see further than others, it is because I bought a pair of binoculars.
3. Re:Could have told us what it is by Anonymous Coward · 2012-06-11 05:42 · Score: 0
  
  this sounds like something a ten-year-old would have found after fifteen minutes of penetration testing
  I *SO* enjoy reading idiotic statements like this on Slashdot, from armchair security/coding/whatever experts. Things are a lot easier to recognize in hindsight, aren't they.
  If it's so trivial and easy to find that a ten year old could have found it after 15 minutes of penetration testing...how long did it take you? Oh, you had no clue until just now? Well, blow me down...
4. Re:Could have told us what it is by Kunnis · 2012-06-11 05:44 · Score: 1
  
  Since the article said the odds of hitting the bug were roughly 1:256, my guess is a programmer casted the return value from memcmp to a char instead of an int.
5. Re:Could have told us what it is by Anonymous Coward · 2012-06-11 05:45 · Score: 5, Insightful
  
  They are casting the result of int strcmp to my_bool, which they have defined as typedef char my_bool.
  Since int is bigger than char, you have really lots of ints than can be 0 when casted to char.
6. Re:Could have told us what it is by autocracy · 2012-06-11 05:46 · Score: 4, Interesting
  
  Well, let's explain it right: the compare function uses a variable type cast that paired with certain compiler flags will improperly reduce a larger number storage to an 8 bit interger. memcmp returns 0 when there's a match, any other value otherwise. When some larger number is interpreted as a character and that number is mod(256), then you get a zero when you truncate the leading numbers.
  Since the hashing function in MySQL has some variable used every time, you get a different number every time that returns a mismatch. 1 in 256 of those mismatches gets reduced to a number that is represented by a zero... which is appropriate to the cast function, but causes issues when used with memcmp.
  
  --
  SIG: HUP
7. Re:Could have told us what it is by Narnie · 2012-06-11 05:49 · Score: 1
  
  1 in 256 attempts? Seems about right when I can't remember my banking password.
  
  --
  greed@All_Evils:~#
8. Re:Could have told us what it is by Anonymous Coward · 2012-06-11 05:51 · Score: 0
  
  The int return value is treated like a signed char. On some systems, the return value actually has values outside of the signed char range. This causes return values other than zero to be interpreted as zero, turning a mismatch into a match.
9. Re:Could have told us what it is by Anonymous Coward · 2012-06-11 05:52 · Score: 0
  
  I've been doing this for twenty years, so eat me.
  I wasn't saying that some poor sod -- all of us poor sods -- failed to do our due diligence; I was commenting specifically on how, in hindsight, it is tough to imagine that this went so long without being officially discovered.
  Maybe you should spend as much time re-reading comments as I do to fully comprehend the meaning, lest some ten-year-old comes along to point out your BS.
10. Re:Could have told us what it is by 0123456 · 2012-06-11 05:55 · Score: 1
  
  If it's so trivial and easy to find that a ten year old could have found it after 15 minutes of penetration testing...how long did it take you? Oh, you had no clue until just now? Well, blow me down...
  Yes, because we should all spend our spare time trying to break random pieces of software.
11. Re:Could have told us what it is by atisss · 2012-06-11 06:19 · Score: 1
  
  Wow, shouldn't there be compiler warning for this?
12. Re:Could have told us what it is by shutdown+-p+now · 2012-06-11 06:27 · Score: 1
  
  In this particular case, it doesn't even need penetration testing. An implicit cast from int to char is something that any C compiler worth its salt will balk at you with default settings (and any developer worth his salt will go even further and compile with warnings as errors). These guys must have explicitly disabled that compiler warning instead. Now they know why it was a bad idea.
13. Re:Could have told us what it is by SteveAyre · 2012-06-11 06:30 · Score: 1
  
  this sounds like something a ten-year-old would have found after fifteen minutes of penetration testing.
  What stopped them finding it is it depends on what memcmp version is being used. GCC builtin ones aren't affected, neither are BSD libc. glibc's is though. Which you use all depends on how it was compiled and it appears the official vendor ones from mysql.com aren't affected. My own systems also aren't, which appears to be because they're using the GCC builtin version.
  Penetration testing'll only find it on the affected versions, if the official mysql.com versions aren't affected then their testing wouldn't have found it because the bug didn't exist on their systems. And since that'll apparently be most of the installed versions out there, it's not going to be something that's been found on many versions in the wild either.
14. Re:Could have told us what it is by Anonymous Coward · 2012-06-11 06:30 · Score: 0
  
  Not if it was explicit typecast which means it was a judgement error of the programmer.
  Otherwise, if it was implicit, then yes, it would throw a common error you might see and not pay attention to since implicit typecast warnings is common for those who are lazy.
15. Re:Could have told us what it is by SteveAyre · 2012-06-11 06:33 · Score: 3, Informative
  
  Yes, it's exactly that. They assumed memcmp returned a value in the range -128..127 - so they've assumed a char was sufficient. And many implementations do indeed return that, but unfortunately not all.
  http://seclists.org/oss-sec/2012/q2/493:
  
  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.
16. Re:Could have told us what it is by Anonymous Coward · 2012-06-11 08:10 · Score: 0
  
  You're explanation is obtuse and slightly inaccurate (there's no casting occurring whatsoever; it's called implicit conversion). Why not just let people see the code for themselves:
  Original code:
  my_bool checkscramble([blah]) { [...] return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE); }
  Horrendous fix:
  my_bool checkscramble([blah]) { [...] return test(memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE)); }
  Better fix:
  my_bool checkscramble([blah]) { [...] return 0 != memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE)); }
  or
  my_bool checkscramble([blah]) { [...] return !!memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE)); }
  The entire MySQL codebase is a pile of garbage. Barely a step up from the PHP codebase. The two deserve each other.
17. Re:Could have told us what it is by Sancho · 2012-06-11 08:41 · Score: 2
  
  Really, though, penetration testing could have uncovered the bug. Most pentesting I've been through has included simple brute-force attacks with the 1000 or so most common passwords. That should easily have succeeded. The report should have said, "We found MySQL open with the username 'root' and the password 'p@ssw0rd'." And someone would read that report and say, "Hey, that's not our password!" And that moment of uncertainty should have provided all the impetus needed to find the vulnerability.
18. Re:Could have told us what it is by bertok · 2012-06-11 09:19 · Score: 1
  
  Wow.
  Suddenly, the decision to have an explicit 'bool' type in newer languages makes a lot more sense!
19. Re:Could have told us what it is by adri · 2012-06-11 09:35 · Score: 2
  
  No. memcmp() is designed to be used by sort functions. IIRC: It's supposed to return:
  0: identical
  +ve: string 2 > string 1
  -ve: string 1 > string 2
  'bool' doesn't cut it. But yes, their comparison was bogus.
20. Re:Could have told us what it is by Anonymous Coward · 2012-06-11 09:39 · Score: 0
  
  FYI: gcc -Wconversion should catch this type of mistake for implicit conversions, and code review should catch the explicit ones ("why are you casting to char here?").
21. Re:Could have told us what it is by LurkerXXX · 2012-06-11 11:05 · Score: 1
  
  Do you know how many years that MySQL accepted February 31st as a valid date? Come on, they aren't going to spend time doing pen testing when they have known hard bugs like that to spend years fixing!
22. Re:Could have told us what it is by Sancho · 2012-06-11 11:12 · Score: 1
  
  That's pretty funny.
  But actually, I was referring to users of MySQL being penetrated by consulting firms as part of a standard security audit.
23. Re:Could have told us what it is by LurkerXXX · 2012-06-11 11:25 · Score: 1
  
  Ohhh, gotcha. I didn' t think that would be an issue. Most folks that care about their data don't keep it MySQL.
24. Re:Could have told us what it is by Anonymous Coward · 2012-06-12 02:01 · Score: 0
  
  Having said that the actual return values of memcmp are not specified.
  They are specified to the amount necessary. If you make any assumptions beyond that, it's your fault.
25. Re:Could have told us what it is by bill_mcgonigle · 2012-06-12 05:36 · Score: 1
  
  And that moment of uncertainty should have provided all the impetus needed to find the vulnerability.
  You under-estimate the strength of a SEP field.
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Like it matters! by bobbied · 2012-06-11 05:39 · Score: 1

Most applications that use MySQL that I've seen decided to use imbeded hard coded usernames and passwords (usually for the SA user) so there was no security anyway. The few solutions I've seen that actually used unique usernames and passwords and not SA, usually used an external authentication method so the database didn't have any passwords to expose.
Finding out about this now doesn't scare me all that much. If you had used a good security design and practice, there should be limited exposure of usernames and passwords, but if your design and practice sucks, expect to get hacked and not be able to do anything about it.

--
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
1. Re:Like it matters! by camperslo · 2012-06-11 05:56 · Score: 0
  
  Doesn't Firefox keep a great deal of user data (history, bookmarks, tags, page metadata etc) in MySQL? Couldn't some of these problems potentially affect a huge number of people as a result by extending what might easily be accessed through browser/plugin vulnerabilities and JS features?
2. Re:Like it matters! by tuffy · 2012-06-11 05:59 · Score: 4, Informative
  
  Firefox uses SQLite, which implements a database management system in a single file. It's not something anyone can connect to remotely.
  
  --
  Ita erat quando hic adveni.
Bad article summary by Anonymous Coward · 2012-06-11 05:41 · Score: 1

Summary is making it look a LOT worse than it is.
- Bug's already been fixed, only what it did was revealed now.
- Bug does not affect binary distributions from mysql.com, Windows included.
- Bug only affects some distros.
Full description here: https://community.rapid7.com/community/metasploit/blog/2012/06/11/cve-2012-2122-a-tragically-comedic-security-flaw-in-mysql
1. Re:Bad article summary by Anonymous Coward · 2012-06-11 08:29 · Score: 1
  
  - Bug only affects some distros.
  So far, the following systems have been confirmed as vulnerable:
  Ubuntu Linux 64-bit ( 10.04, 10.10, 11.04, 11.10, 12.04 ) ( via many including @michealc )
  OpenSuSE 12.1 64-bit MySQL 5.5.23-log ( via @michealc )
  Debian Unstable 64-bit 5.5.23-2 ( via @derickr )
  Fedora ( via hexed and confirmed by Red Hat )
  Arch Linux (unspecified version)
  
  Feedback so far indicates the following platforms are NOT vulnerable:
  Official builds from MySQL and MariaDB (including Windows)
  Red Hat Enterprise Linux 4, 5, and 6 (confirmed by Red Hat)
  CentOS using official RHEL rpms
  Ubuntu Linux 32-bit (10.04, 11.10, 12.04, likely all)
  Debian Linux 6.0.3 64-bit (Version 14.14 Distrib 5.5.18)
  Debian Linux lenny 32-bit 5.0.51a-24+lenny5 ( via @matthewbloch )
  Debian Linux lenny 64-bit 5.0.51a-24+lenny5 ( via @matthewbloch )
  Debian Linux lenny 64-bit 5.1.51-1-log ( via @matthewbloch )
  Debian Linux squeeze 64-bit 5.1.49-3-log ( via @matthewbloch )
  Debian Linux squeeze 32-bit 5.1.61-0+squeeze1 ( via @matthewbloch )
  Debian Linux squeeze 64-bit 5.1.61-0+squeeze1 ( via @matthewbloch )
  Gentoo 64-bit 5.1.62-r1 ( via @twit4c )
  SuSE 9.3 i586 MySQL 4.1.10a ( via @twit4c )
  OpenIndiana oi_151a4 5.1.37 ( via @TamberP )
2. Re:Bad article summary by isorox · 2012-06-11 08:33 · Score: 1
  
  Summary is making it look a LOT worse than it is.
  - Bug's already been fixed, only what it did was revealed now.
  - Bug does not affect binary distributions from mysql.com, Windows included.
  - Bug only affects some distros.
  Full description here: https://community.rapid7.com/community/metasploit/blog/2012/06/11/cve-2012-2122-a-tragically-comedic-security-flaw-in-mysql
  They claim ubuntu 10.04 64 bit is vulnerable. That's my laptop distro, and after 5,000 attempts I can't break in.
  The linked memcmp program at http://pastie.org/4064638 indeed says I'm vulnerable, so why can't I break in?
How accurate is that vulnerable list by tuxrulz · 2012-06-11 05:50 · Score: 1

The author of the article mention a couple of distributions found vulnerable to this bug. In one of them is Arch Linux. But he also said that systems with versions up to 5.1.61, 5.2.11, 5.3.5, 5.5.22 are vulnerable. Then... How the heck can Arch (a rolling release distribution) be affected if they have an updated version of the package already in place, lol. The article is dated June 11, Arch fixed upstream release was committed May 13. So it has been already fixed for nearly 2 months.... wow https://projects.archlinux.org/svntogit/packages.git/log/trunk?h=packages/mysql
1. Re:How accurate is that vulnerable list by tuxrulz · 2012-06-11 05:52 · Score: 1
  
  My bad, the update was not committed May 13, was April 13. so yes, nearly 2 months.
2. Re:How accurate is that vulnerable list by Rich0 · 2012-06-11 13:34 · Score: 1
  
  Yup, when somebody emailed me this news in a panic I checked and the bug was fixed on Gentoo over a month ago, though if you were on itanic or sparc you got it a bit late (still a week or two ago). The article only refers to 64-bit Gentoo, but as far as I can tell it should be fixed on all the security-supported archs (and likely on the non-security ones by now also).
Didn't anyone learn from the Wii? by Dwedit · 2012-06-11 06:04 · Score: 1

Sounds like the bug on the Wii.
There was a bug on the Wii where it used string comparison functions to compare signatures, instead of memory comparison functions. So it terminated at the first null character. So you could fakesign anything easily after 256 tries.
From what little information is on that page, it sounds like the exact same problem.
1. Re:Didn't anyone learn from the Wii? by shutdown+-p+now · 2012-06-11 06:30 · Score: 2
  
  No, this is a different problem. This one is about casting the value returned by memcmp to char (it returns an int). On most systems, int is 32-bit, char is 8-bit, and such a cast is basically equivalent to taking the low 8 bits of the int. So when memcmp returns a non-zero value (meaning "not equal"), which has the lower 8 bits of the int all set to zero, they get zero when they cast it to char, and then interpret that as "equal".
2. Re:Didn't anyone learn from the Wii? by Anonymous Coward · 2012-06-12 00:45 · Score: 0
  
  Sounds like someone needs to stop being an arm chair computer scientist, awful weaboo.
It doesn't affect RHEL or Centos by innocent_white_lamb · 2012-06-11 06:04 · Score: 1

RHEL and Centos are not affected by this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-2122
http://lists.centos.org/pipermail/centos/2012-June/126719.html

--
If you're a zombie and you know it, bite your friend!
FUD? by t4ng* · 2012-06-11 06:07 · Score: 2

Sounds like it is only in a small subset of versions. From the source article...

"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.
As far as I know, official vendor MySQL and MariaDB binaries are not vulnerable."
1. Re:FUD? by Anonymous Coward · 2012-06-11 06:17 · Score: 0
  
  The fact that they are testing passwords with memcmp AT ALL should be raising klaxons and flashing lights. Have these people never heard of timing attacks? Oh wait, they're MySQL developers. They probably haven't.
2. Re:FUD? by Anonymous Coward · 2012-06-11 06:37 · Score: 0
  
  From the sound of it, they are comparing hashes of the two strings they want to compare combined with a random nonce, maybe as part of a challenge-response.
  It would be difficult to do a meaningful timing attack if there's a nonce.
3. Re:FUD? by Anonymous Coward · 2012-06-11 06:48 · Score: 0
  
  I'm trying this right now on a slow windows machine. Over 1000 connection attempts per second. No dice.
if its not fixed it aint fixed by Anonymous Coward · 2012-06-11 06:52 · Score: 0

"...even if the authentication bypass vulnerability is fixed."
then you aint fixed the issue have you?
Re:use a toy database.. by Anonymous Coward · 2012-06-11 07:18 · Score: 0

You don't get these issues on BSD running MySQL, either.
Anyone using glibc is begging to be hacked.
Are you vulnerable? by Anonymous Coward · 2012-06-11 07:37 · Score: 0

Run this on your MySQL box to see if you're vulnerable. Worked for me and was able to gain root access in 2 seconds running MySQL 5.5.22
for i in `seq 1 1000`; do mysql -u root --password=bad -h 127.0.0.1 2>/dev/null; done
It appears to me that... by Lisias · 2012-06-11 07:48 · Score: 1

... the attacks must have access to the DB first.
If my daemons are firewalled, my MariaDB server only accepts requests from 127.0.0.1 and my authentication code lives out of the httpdocs filesystem (PHP *don't have* to run every script from the httpdocs filesystem!), I don't see how the attacker could try this on my machine without rooting it first.
In this case, the MariaBD passwords are the least of my worries.
Or I'm wrong?

--
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
Check yourself before you wreak yourself by Anonymous Coward · 2012-06-11 08:01 · Score: 0

for i in `seq 1 1000`; do mysql -u root --password=bad -h 127.0.0.1 2>/dev/null; done
1. Re:Check yourself before you wreak yourself by GPLHost-Thomas · 2012-06-11 19:05 · Score: 1
  
  You might want considering using socket files rather than networking though, when connecting to MySQL (eg: use localhost and not 127.0.0.1). Or even better: let the MySQL client library decide for you (eg, don't specify -h). It might sound silly, but even PHP authors didn't understand the fact that a correctly MySQL client lib doesn't need the host to be specified.
Another reason by Billly+Gates · 2012-06-11 08:52 · Score: 2

To avoid having your db serve live web content without an authentication server in between. It costs more money and most companies staring out use an ISP with a single server with everything but that increases your chances of being hacked exponentially.

--
http://saveie6.com/
"...official MySQL binaries aren't vulnerable" by spxZA · 2012-06-11 20:17 · Score: 1

http://seclists.org/oss-sec/2012/q2/493
Lookout for that molehill! Yes, some versions are vulnerable, and everyone is having a hissy fit about this. I've tested every single copy of various versions of MySQL that I have running, and they are not vulnerable. And I'm running MySQL on Windows, Arch, RHEL, Ubuntu and CentOS.
Joke's on them! by Anonymous Coward · 2012-06-11 22:09 · Score: 0

My root password is blank!
I only use it for college stuff.