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 …
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.)
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.
This post has been deleted by its author
This post has been deleted by its author
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?
This post has been deleted by its author
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...
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.
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.
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).
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.
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*)
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
