All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Flaw Grants Access to 900,000 Servers By Guessing Username A flaw in MySQL and MariaDB
Just got this on one of my monthly newsletter
A flaw in MySQL and MariaDB databases allows someone to merely guess a username and be granted access to 900,000 Internet connected servers while able to attempt logging in 256 times. MySQL and MariaDB databases both assign an SHA-encrypted token to every user who logs in to the server so users only have to log in at the beginning of the session, not every time they send a request to the database. This flaw is due to an error when comparing the token to the expected value. Some editions of the database can not tell if the login is authentic or not, assumes that it is, and allows users access whether the password is correct or not.
Comments
Who exposes MySQL to the Internet? Sounds suicidal to me.
I don't even turn on networking most of the time, and if I do, it's on private LAN interfaces and restricted to certain hosts.
uhm l2 code? Who the hell does that..
Raindog many reason? Remote admin staff? Collaboration? Etc?
Remote admin...maybe. There are some nice MySQL tools that work with the DB. e.g., MySQL Workbench, TOAD for MySQL, etc. I'm thinking most people don't use them.
Still, I think the vast majority of enterprises do not allow direct connections to DBs over the Internet.
That makes zero sense. That's like saying Facebook stock fell and a hush fell over an audience and they're somehow related.
You are not into philosophy, Are you?
As I understood it, the flaw was that they stopped comparing the given and expected token past the end of the given token instead of immediately failing if the lengths of the two differed. Given that, an attacker simply had to attempt authentication with, at most, all possible single-character tokens: with an 8-bit character set, 2^8 == 256 possibilities. This is flagrantly wrong; see the oss-sec post for actual details.
One of my minors in college, actually, hence the observation.
@raindog How many minors can you take? we are only allowed to take 1 major 1 minor.
OK, I have to admit exposing databases is a bad thing that should be avoided. Remote admin could work over VPN, SSH, port forwarding, whatever, and even then we can restrict to certain IPs, for example a VPS or two to have redundancy...
My personal way is to log into an internal VPS and work from there. Just forward the required ports over SSH after I log in. And SSH can be pretty secure.
M
Where does that number come from?
Probably a quick connect to all possible IPv4 hosts on port 3306 :P
M
M
As far as I am aware, only certain versions of MySQL (or to be more specific, versions of MySQL that were compiled with specific compilers) are vulnerable to this. In other words, 'the total amount of MySQL servers exposed' is not an acceptable metric to determine how many servers are vulnerable.
Sounds like someone didn't do his homework when coming up with the 900k figure.
As many as you qualified for (took all the credits for)...this was in the U.S. in the 1990s.
All newspaper IT writers here are doing the same kind of "research" if any. Writing a script to probe ports on IPv4 would be too hard for them, they struggle with grammar even.
I find out of a new "most destructive ever" virus every couple of days and usually it is announced by x or y antivirus vendor who's product already detects it, of course.
M
Not in City College(CCNY).
any test?
I compiled mine with the usual mysql build script.
I haven't tested it myself so i can't confirm that it does what its supposed to do.
This error is related to gcc not mysql itself details here http://seclists.org/oss-sec/2012/q2/493
Beside that even that test code fail your MySQL can be safe. You can use following code to test
!/usr/bin/python
import subprocess
while 1:
subprocess.Popen(“mysql -u root mysql –password=blah”, shell=True).wait()
Hows that? What what i understand the essential part from the bug report is:
So the MySQL people relied on that memcmp's return value is between -128 and 127
even though the specification says that it can be any integer.
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.
Read the article which I linked few posts earlier.
Do you mean me?
Yes. I'm one the mobile and I can't copy-paste your nick
Haha ok :P
I've actually quoted parts from the article in my post and pointed out why its MySQLs fault
@gsrdgrdghd - the trick is that when compiling source code with SSE enabled the memcmp instead comparing one byte each time is comparing four bytes each time. It returns the result of subtraction of four-byte vectors. When the result is casted to char the difference in type sizes results with assigning of only last byte
#include <stdio.h>
#include <stdlib.h>
int main(void) {
int one, two, ret;
time_t start = time(0);
time_t now;
srand(getpid()*start);
while (1) {
one = rand();
two = rand();
ret = memcmp(&one, &two, sizeof(int));
if (ret < -128 || ret > 127)
break;
time(&now);
if (now - start > 10) {
printf("Not triggered in 10 seconds, *probably* not vulnerable..\n");
return 1;
}
}
printf("Vulnerable! memcmp returned: %d\n", ret);
return 0;
}
Take this code and compile with GCC
vulnerable
$ gcc test.c -o test
not vulnerable
$ gcc -march=native -O3 -pipe -fomit-frame-pointer -funroll-loops test.c -o test
I don't see how thats gcc's fault then. memcmp returning a 4-byte value is perfectly fine since it's return type is an integer. The MySQL devs just handled that integer wrong by casting it to a char.
@gsrdgrdghd - yes and no, sometimes source code is written for generic compilation without SSE and similar stuff. Beside that it's hard to test software using all possible compiler switches on all possible platforms, remember that MySQL runs on other platforms too - for Windows memcmp returns -1,0,1
Bug description states that
vulnerable
so versions compiled by vendors are save. Anyway you can use Python code from one of my previous posts and test your own instance
Wow! That sounds... intense.
So, this is a fault on several levels. The programmer, gcc, processors, etc :S
Btw, someone have a vulnerable mysql? I was looking in all my servers without success u_u
So, this is a fault on several levels. The programmer, gcc, processors, etc :S
Why is that fault on gccs or the processor's level? It behaved exactly according to the specification.