MariaDB and MySQL Authentication Bypass Exploit

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."

Comments

holy motherfucking cheetah

[gl4ss]

"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..

Re:holy motherfucking cheetah

[Anonymous Coward]

And that is why we use fail2ban.

Re:holy motherfucking cheetah

[WrongSizeGlass]

a 1/256 chance of getting in when using a valid username and invalid email? I don't like those odds.

Re:holy motherfucking cheetah

[WrongSizeGlass]

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.

Re:holy motherfucking cheetah

[SteveAyre]

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

Re:holy motherfucking cheetah

[hairyfeet]

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!

Could have told us what it is

[Anonymous Coward]

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.

Re:Could have told us what it is

[Anonymous Coward]

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.

Re:Could have told us what it is

[autocracy]

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.

Re:Could have told us what it is

[SteveAyre]

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.

Re:Could have told us what it is

[Sancho]

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.

Re:Could have told us what it is

[adri]

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.

Re:Like it matters!

[tuffy]

Firefox uses SQLite, which implements a database management system in a single file. It's not something anyone can connect to remotely.

FUD?

[t4ng*]

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."

Re:Didn't anyone learn from the Wii?

[shutdown -p now]

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".

Another reason

[Billly Gates]

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.