Feeds

back to article Password flaw leaves MySQL, MariaDB open to brute force attack

A basic flaw in the password software used by MySQL and MariaDB allows a brute-force attack to bag the password and gain full root access in a few seconds, according to details published by security researchers. MariaDB security coordinator Sergei Golubchik explained the flaw, which involves a casting error when passwords are …

COMMENTS

This topic is closed for new posts.
FAIL

Erm, oops?

0
0

Hum.

Can't seem to confirm that Fedora 17 is vulnerable, according to the one-liner. Ran it three times, it didn't work once (that's 3,000 attempts). Using the same command from the one-liner with my actual password succeeds.

0
0
Silver badge
Facepalm

There is not enough WHY on the Internet for why MySQL daemon sockets should be visible from the Interwebs.

3
0
Bronze badge

Do you run MySQL on the LAN?

I assume that there's a "malicious code running a PC on the local network" attack.

Several of the vulnerable systems are specifically 64 bit, is that a factor or is it just what all the cool kids use now? (who don't have Atom-processor PCs with only 2 GB RAM - like me. As a plus, it is a pretty cool tablet, Dell Latitude ST. As a minus, it frequently locks up for 60 to 65 seconds with all applications unresponsive. There's a rumour that the fix for that is to un-install the Atheros management software for the WLAN/Bluetooth card.)

0
0

You're missing the point

Shared hosting? Privilege escalation? Even if there were no MySQL installations in existance with an Internet facing network interface, this would still be a massive problem.

1
0
Anonymous Coward

Remote access

So if you've done what is recommended and made it so that the root user can only be used on the server itself then how exploitable is this?

0
0
Silver badge

Re: Remote access

Is it possible to create (spin up?) a Linux VM that doesn't have a root user? (Is this what you are referring to anyway?)

0
0

Re: Remote access

Yes, you could make a Linux (VM or otherwise) that doesn't have a user named 'root' by simply renaming the super user account. That's not what they mean, though.

MySQL has its own notion of users, completely independent of the users of the OS it runs on. There is a built-in account that gets automatic complete access to all databases and it is normally also named 'root'. You can rename that account, you can stop it from being accessed remotely and you can even stop the entire database from being accessed remotely.

But, in many distros and ISP offerings, it comes out of the box named 'root' and accessible from anywhere.

3
0

This post has been deleted by its author

This post has been deleted by its author

Anonymous Coward

But the code is reviewed by many eyes due to it being open source so it must be bug free?

3
5

<quote> But the code is reviewed by many eyes due to it being open source so it must be bug free?</quote>

Presumably that's how someone found it.

3
0
Silver badge

memcmp! FFS!

As a someone familiar with testing, I can see how something like 'sometimes the wrong password is accepted' doesn't get tested - I don't think I've ever seen a security test plan that just keeps trying the wrong password in a functional security test! However, the weakness should have been discovered during non-functional security testing - an obvious way to attempt to DDoS a DB (or any other app) is with repeated bogus login attempts.

But what I'm really struggling with is how a function like memcmp can have (a) been screwed up and (b) have its screwup missed in regression testing. How can one have any confidence in a library where a function to compare two sequences of bytes does not work properly?

2
0

This post has been deleted by its author

Anonymous Coward

Re: memcmp! FFS!

No, I have looked at it in more detail and there is nothing wrong with memcmp() as such, it returns non-zero if the two arrays differ, just as it should.

The problem is the coders ASSUMED this non-zero value would always fit in to a single byte, which they returned from the function thus dropping the higher bits of the value.

Of course, you could have a value like 0x200 that is clearly non-zero, but not if you chop off the high bits!

Once again, assumption is the mother of all major foul-ups...

7
0
Silver badge

C++ or C99 FFS!

They've cast the result of int memcmp() to a homespun bool that's actually char. That means they discard everything but the least significant byte.

Most memcp's return +1,0 or -1, so the cast works. But memcmp doesn't have to. Some implementations take advantage of this, and if such an implementation returns a result with the low byte set to zero - e.g. 256, -256, 512, -512 etc... - then it's cast to zero. Et voila! The code believes the blocks are identical, even though they're not.

This is basically an argument for using using a genuine bool.

4
0

Re: memcmp! FFS!

Rtfm. It's a casting problem. If the result of the memcmp is outside a signed char then there's a problem. Chances are memcmp returns an int but the MySQL coders erroneously cast the result to a signed char discarding high significant bits.

If you don't understand this, fine, but the article was clear on this. The problem is not with the OS.

2
0
Bronze badge

Simple security

This is why, by default, you just don't expose things to the Internet unless you absolutely, positively have no other way to achieve your aim.

How long's the bug been there? How long have OTHER people apart from this researcher known about it and just kept quiet?

All made moot by NOT letting mysql bind to the external interface, by firewalling off any port you don't specifically intend to expose to strangers, and by following other basic security practices (such as not letting ANYTHING pass through SQL statements to MySQL without extreme amounts of sanitisation). And, despite what some are saying, MySQL on any half-sensible distro binds only to localhost and you have to specifically change the config to make it do anything else. If your distro doesn't, question why NOW and review your choice of distro.

Strange, really, that this has arisen just as lots of large websites start losing their ENTIRE user databases to hackers, which is a situation, in and of itself, that I find odd. How can any external entity get access to some machine that will allow them to dump entire user tables with hashes? Are they not using an authentication system that is isolated from the front-facing systems and can only return YES/NO answers to them when they provide login details (and thus can only be "attacked" by quite obvious brute-forces and/or an internal agent with access to the authentication network)?

Basic security, people. Limit the attack surface and thus possible access, inputs and responses and you INSTANTLY limit the amount of damage that someone can do (and that they can do unnoticed).

3
0
Holmes

...on the other hand...

...No-one with more than two neurons would leave a MySQL port open to the outside world.

So, it's a FAIL, but only of any consequence when compounded with an even bigger one.

1
0
g e
Silver badge

Re: Simple security

Absolutely. Your average webserver only needs :80 and :22 visible to the world anyway and MySQL should be bound to 127.0.0.1. If you need a separate DB server then put them on the same private network and only expose the webserver to the world.

0
2
Vic
Silver badge

Re: Simple security

> Your average webserver only needs :80 and :22 visible to the world

I'm quite keen on :443 as well...

Vic.

1
0

Re: Simple security

Your grasp of theory is impeccable. I do, though, wonder about your practical chops.

0
0

Re: Simple security

Actually, you only really need 80 and perhaps 443... I would suggest that SSH should either be on a non-standard port and/or only accessible via an internal interface.

1
0
Boffin

The C library was not at fault.

This is an integer overflow vulnerability resulting from the mistreatment of the return value of memcmp.

The memcmp function can return any integer, but MySQL converted its return value to my_bool (a typedef of char), causing an integer overflow if memcmp returned a value outside the range of a char (typically -128..127). An implementation of memcmp that returned values in -128..127 would hide this vulnerability, but another, equally valid implementation of memcmp returned values outside that range.

What is most shocking is how few programming languages (even "modern" languages like Java, Caml, ...) actually bother to handle integer overflows properly.

3
0
Silver badge
Mushroom

@Testy McTester the testers' tester

I disagree with your last paragraph, Testy.

Firstly, C++11 makes a good stab at disallowing narrowing conversions. (And fuck is it annoying.) But those casts are often useful, and there are plenty of times you can prove they will be safe; although I grew up programming assembler, so YYMV.

What I found shocking was the use of char as a boolean. A true boolean type (C++ bool or C99 _Bool) would have converted every non-zero value to true, and there wouldn't have been a problem. I would never have spotted the bug because I would have expected a type called my_bool to have boolean semantics. (More fool me. *sigh*)

4
0

Re: @Testy McTester the testers' tester

I expect antiquated code was allowed to persist. But, even if you have to roll your own boolean (and once upon a time in the early Mesolithic you indeed had to) defensive coding says to do

return (my_bool)(foo != 0);

But you shouldn't

return (my_bool)foo;

Apart from not opening holes, the first version also tell the people who come after you that you are normalizing and not just casting away the high bits.

1
0
This topic is closed for new posts.