Password flaw leaves MySQL, MariaDB open to brute force attack
Ubuntu, Fedora, and openSUSE versions vulnerable
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
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 checked using the memcmp function, giving a one-in-256 chance of access being allowed whatever the login.
"If one knows a user name to connect (and "root" almost always exists), she can connect using *any* password by repeating connection attempts. ~300 attempts takes only a fraction of second, so basically account password protection is as good as nonexistent," Golubchik said.
He assured that gcc built-in memcmp and BSD libc memcmp are safe, but Linux glibc sse-optimized memcmp is not where memcmp() can return an arbitrary integer outside of the -128..127 range. MariaDB and MySQL versions up to 5.1.61, 5.2.11, 5.3.5, and 5.5.22 should be considered at risk.
According to testing by MetaSploit creator HD Moore, 64-bit Ubuntu versions 10.04, 10.10, 11.04, 11.10, and 12.04 are all vulnerable, as is Fedora and OpenSUSE 12.1 64-bit MySQL 5.5.23. Debian and Gentoo's 64-bit Linux builds appear to be in the clear, as are official builds of MySQL and MariaDB (the latter released in April); Red Hat has confirmed its Enterprise Linux 4, 5, and 6 are secure.
Moore said that a quick scan of 1.74 million MySQL servers showed over 50 per cent (879,046 against 863,920) were vulnerable to the attack, and that security testers have already built software that could fully exploit the flaw.
Oracle has already dealt with this issue in its April security update, and there are separate patches for MariaDB and MySQL. Admins are advised to regard this as a priority, given the simplicity of the attack. ®
COMMENTS
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...
@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*)
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.
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
