Security vulnerability in MySQL ubuntu

http://seclists.org/oss-sec/2012/q2/493

by mjschultz • 14 years ago

125 109 14 years ago

ushi2• 14 years ago

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.

How do you know, how the Ubuntu devs compiled their mysql server?

dangrossman2• 14 years ago

Try to connect to MySQL as root with a made-up password several hundred times. If you successfully connect, the bug is present and you know how it was compiled.

gringomorcego• 14 years ago

where is the perl one-liner :P?

ushi2• 14 years ago

Hehe, ok ok.

mjschultz4• 14 years ago

Well, the Ubuntu part came from HD Moore [1]. I haven't been able to confirm it on my Ubuntu 12.04 virtual machine instance though, nor does my virtual machine appear to trigger the bug using the CVE-2012-2122 checker [2].

But, that is just my single VM instance and I would assume HD Moore knows what he is doing.

[1] http://pastie.org/private/903voijkkz8nmde3yqj4rw

[2] http://pastie.org/4064638

zzzzzzzzz• 14 years ago

I can confirm. Ubuntu 12.04 LTS (64 bit).

gyaresu• 14 years ago

One-liner: $ for i in `seq 1 512`; do echo 'select @@version;' | mysql -h 127.0.0.1 -u root mysql --password=X 2>/dev/null && break; done

Via HDMOORE on twitter

tptacek11• 14 years ago

This is a vulnerability in the authentication scheme used in the MySQL wire protocol, meaning attackers need to be able to connect to your MySQL database directly to exploit it. Attackers should never, ever be able to connect directly to your MySQL database directly. If you can connect to your MySQL instance directly from your Macbook in your living room, fix it right now.

jeffdavis• 14 years ago

While your advice may be prudent, that does not excuse poor security.

dhx2• 14 years ago

―Attackers should never, ever be able to connect directly to your MySQL database directly.

mySQLgame[1] demonstrates that domain logic can be successfully implemented within a publicly accessible database[2]. It would be better to reword your statement to:

Minimise the attack surface by preventing unnecessary access

There are times where public access to a database server make perfect sense. It is the reason why database servers implement TLS client certificate verification, Role Based Access Control (RBAC) and other security features which a typical application (with domain logic at the application layer) has no hope of implementing correctly.

[1] http://mysqlgame.com

[2] http://martinfowler.com/articles/dblogic.html

tptacek11• 14 years ago

I would generally avoid building applications that assume clients are going to speak directly to the database. We see a couple of them every year (it's a common pattern in enterprise applications) and they tend to be horrorshows.

In any case, the typical web app deployed by HN readers has no business having an exposed MySQL port.

mibbitier2• 14 years ago

Either use iptables to lock it down to a particular IP or set of IPs. Or setup ssh tunnelling to expose a remote mysql server as a local port. You should assume mysql is insecure and needs protecting.

nodata• 14 years ago

The counter argument being that if you expose lots of MySQL servers directly to the Internet, you end up with a product much more suitable to being exposed to the Internet.

halayli• 14 years ago

With this logic, let's not secure any software that you cannot connect to it directly.

einhverfr4• 14 years ago

Before we forked LedgerSMB, the SQL-Ledger author's attitude was that unless you can exploit the software without logging in it doesn't count. It's only accounting software anyway so why would anyone want to break in? Not only that but timestamps were perfectly acceptable as session id's and they didn't even have to be stored on the server, just checked to see if they were recent.

Thus began years of efforts on our part of security fixes, which I would not have started except that I had customers to support.

tptacek11• 14 years ago

What "logic" is this? Where are people getting the idea that I'm instructing them not to patch MySQL?

dawkins2• 14 years ago

What is the best way to enable replication without access to the database? ssh tunnel?

viraptor2• 14 years ago

Vpn, gre, whatever flavour you like. That's for replication between sites though. Internally there's nothing wrong with direct connection.

_b8r02• 14 years ago

Best? Probably an infrastructure VPN across databases. Have you database listen on the MPLS link and limit access to the service based on IP addresses and strong authentication.

Cheapest? SSH tunnel or openvpn point to point link.

mike-cardwell13• 14 years ago

"Never" ... You are aware of the existence and mass use of shared web hosting systems right?

mmaunder2• 14 years ago

Right. By this logic MySQL doesn't need authentication, never mind privileges.

tptacek11• 14 years ago

Don't use shared web hosting.

jaryd• 14 years ago

metasploit module:

https://github.com/rapid7/metasploit-framework/blob/master/m...

speleding• 14 years ago

I agree with the sentiment, but just to be clear: There are valid reasons to allow MySQL to talk to the wider internet, the most important one being off-site replication.

If you do need your mysql to be exposed to the internet you can use bind_address=x.x.x.x or some kind of firewall.

_hnwo• 14 years ago

while true; do mysql -u root mysql --password=fail; done

jms• 14 years ago

For anyone running phpMyAdmin, make sure to lock it down.

Here's a guide for limiting access to it by IP address via the apache config for Ubuntu users:

http://mixeduperic.com/ubuntu/how-to-restrict-phpmyadmin-ip-...

jontas• 14 years ago

Just tried the various one-liners mentioned in the comments on a hardy (8.04) release using mysql 5.0.51a and could not get in.

This is a slicehost box, so I'm assuming that can be extrapolated to mean that anyone using ubuntu on slicehost is probably safe.

taligent• 14 years ago

Bad assumption. Very, very bad assumption.

pwaring3• 14 years ago

It depends what version they are using. My local dev machine (using Precise) is vulnerable, so Slicehost customers running a more recent version than Hardy might be affected.

drivebyacct2• 14 years ago

That's a horrid assumption, is verifiably wrong and what in God's name are you doing on Hardy? You just screamed "ignore me" three times in two sentences.

postfuturist• 14 years ago

I'm not the poster, but Hardy is an LTS release that is still supported in server configuration. It's quite a bit newer than Centos/RHEL 5, which is widely deployed on servers (potentially the most popular platform for existing deployments, still).

captn3m02• 14 years ago

This is also important in other environments, for instance shared hosting where you may connect to localhost, or places where you may have given non-admin shell access to a developer (assuming they could not connect to mysql root user).

This is a serious vulnerability. Especially since the latest ubuntu seems to be affected(I'm on mint 13, and it is)

See Ready shodanhq query for latest mysql version:

http://www.shodanhq.com/search?q=port%3A3306+5.5.22-0ubuntu1

dhx2• 14 years ago

This vulnerability could also assist with local privilege escalation. If an attacker managers to use a vulnerability in a web application to execute code as a web user account, they can likely access the MySQL server instance via the loopback interface (perhaps a Unix domain socket too?).

captn3m02• 14 years ago

So if I try logging in with phpmyadmin 256 times, will I succeed?

darklajid• 14 years ago

Maybe.

If you roll a dice 6 times, will one result be a 6?

Pfiffer• 14 years ago

Probably.

vladd• 14 years ago

The probably of NOT hitting a 6 value even after six throws is:

(5/6)^6 = 0.335

For the original question:

(255/256)^256 = 0.367

so yes, you'll succeed in 63.3% of the cases.

willvarfar2• 14 years ago

I'd love to see the code; quite how they are not comparing a memcmp to 0 would be interesting to see...

tedunangst5• 14 years ago

There is a check_scramble function which returns a my_bool, presumably a char typedef. That function itself directly returns the result of memcmp. If your memcmp implementation returns the full range of int values (allowed), 1/256 of them will have a 0 low order byte, which will then compare equal to zero when the check_scramble call is tested.

This is why real C programmers use int as their bool type. :)

darnaut• 14 years ago

> This is why real C programmers use int as their bool type. :)

It has the same problem if a wider type (e.g. long) is assigned to it. Use _Bool instead.

riledhel• 14 years ago

Here you can see a copy of the MariaDB source code and the file in question https://github.com/atcurtis/mariadb/blob/master/sql/password...

mjschultz4• 14 years ago

Here is the fixed version of the MySQL code: https://bazaar.launchpad.net/~mysql/mysql-server/5.1/view/35... (line 534 didn't have the test()) previously)

willvarfar2• 14 years ago

yeap, strange; I'd have thought the obvious natural code would have been:

    return 0 == memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE)

As in, return a bool on whether it matched.

I mean, as I read it, the function returns true if they don't match?

tedunangst5• 14 years ago

From the mysql commit: Date: 2012-04-06 09:04:07 UTC

That's two months ago. Looking at the changelog (http://dev.mysql.com/doc/refman/5.1/en/news-5-1-63.html), they piled in a bunch of other changes like "use less disk space". This should have gone out pronto. I feel it's not the kind of thing you sit on until your next quarterly release is scheduled.

[oh wait, this is worse. mysql 5.1.63 was actually released a month ago. But they only now tell us what the security bug was? Meanwhile the bad people have had a month to diff sources? Double unhappy.]

einhverfr4• 14 years ago

wow.....

What ever happened to public disclosure as soon as a patch is released?

I have been bit twice by problems relating to difficulties getting security fixes/announcements out in time. In my defence I was trying to patch a difficult codebase and this just took a long time. For example, there was a full SQL injection audit that took us two months to complete early on, and there was an issue of XSRF vulnerabilities which could not be effectively patched in a production release.

But waiting a month to announce the security issue after the release was out strikes me as hard to justify.

mattbee• 14 years ago

I've been trying this on lots of our customers' boxes and can't exploit it - no matter how many times I've tried I always get turned away when retrying root's password, e.g. trying "while true; do mysql -u root mysql --password=baha; done" does not yield access on any of:

Debian lenny 32-bit 5.0.51a-24+lenny5

Debian lenny 64-bit 5.0.51a-24+lenny5

Debian lenny 64-bit 5.1.51-1-log

Debian squeeze 64-bit 5.1.49-3-log

Debian squeeze 32-bit 5.1.61-0+squeeze1

Debian squeeze 64-bit 5.1.61-0+squeeze1

Ubuntu lucid 64-bit 5.1.62-0ubuntu0.10.04.1

So I'm not inclined to think it's as bad as made out by the simple exploit above.

Negitivefrags2• 14 years ago

I would imagine you have to try a different password each time.

dangrossman2• 14 years ago

Why would you imagine that? The bug is that what password you provide doesn't matter.

mike-cardwell13• 14 years ago

It works exactly as written on my completely up to date 64 bit Ubuntu 12.04 laptop running "5.5.22-0ubuntu1"

dfc• 14 years ago

Is the bug limited to ubuntu?

tedunangst5• 14 years ago

The bug is most definitely in mysql. Its manifestation depends on compiler/library, and it appears ubuntu is the most prominent afflicted platform, but there could be others. Relying on the bug being limited is very thin ice.

pwaring3• 14 years ago

Can anyone view the MySQL bug report linked to from the email? I get 'access denied' each time I try.

gouranga7• 14 years ago

Doesn't surprise me.

Ubuntu always ship fucked up, broken, shitty MySQL versions.

Look at the one that is current HEAD on 10.04 LTS. It's got so much broken stuff in it, we had to move everything to a spare windows machine where we could stick a later version on without screwing up the machine (DBs for: team city, jira, crucible).

viraptor2• 14 years ago

Why migrate to a completely different environment? I'd recommend just installing some version of percona server (mySQL flavour) instead. You get both better software and upstream version instead of a repackaged one.

gouranga7• 14 years ago

It was what was there as a piece of duct tape for the minute.

I'm in the process of binning it all and moving to Debian which is actually trustworthy...

StavrosK• 14 years ago

Why would you screw up the machine if you just installed the latest deb?

gouranga7• 14 years ago

libmysqlclient dependencies.

air• 14 years ago

It's squarely a MySQL bug, you can't put any blame on Ubuntu here.

gouranga7• 14 years ago

It is but they've fixed it in MySQL and Ubuntu have pinned the HEAD mysql build to the broken one and have pretty much stopped supporting it. LTS my arse.

dawkins2• 14 years ago

"Because the protocol uses random strings, the probability of hitting this bug is about 1/256."

Why 1/256?

jontro• 14 years ago

Because when the return value is truncated to a char, the last two bytes in the int would have to be 0x00, which is 1/256 assuming the return value is a completley random int.

rlpb• 14 years ago

It looks like this is being tracked in Ubuntu here: https://bugs.launchpad.net/bugs/1011371

Unfortunately Oracle's stewardship of MySQL appears to be a closed model. There is no public access to their bug tracker, and distributions struggle to keep up with security updates because the details of their fixes in the source are not published. The future of MySQL appears to be in one of the MySQL forks.

See https://lists.ubuntu.com/archives/ubuntu-server/2012-Februar... and https://lists.ubuntu.com/archives/ubuntu-server/2012-Februar... for details.

ios84dev• 14 years ago

What about http://bugs.mysql.com/?

brg1007• 14 years ago

Any chance that this vulnerability is linked with the recent hashed password lists disclosure ?

mmaunder2• 14 years ago

Has anyone managed to actually repro this. I've tried it on a wide variety of systems I run and no repro. Just looking for anecdotal data on how many systems are affected. To me it doesn't seem like a high percentage.

mjschultz4• 14 years ago

Here is the reference from the Ubuntu CVE tracker: https://bugs.launchpad.net/bugs/cve/2012-2122. So yes it looks like it is confirmed.

Also, the associated bug report: https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/101....

pwaring3• 14 years ago

I can reproduce it on my Ubuntu laptop (amd64 precise), so it definitely exists.

Apreche• 14 years ago

I am trying to make it work on my Ubuntu 12.04 VBox VM. I have mysqld Ver 5.5.22-0ubuntu1, which is the supposedly affected version. I can not reproduce it.

I thought at first it might be because I do not have a root password (it's a VM) so trying to use any password at all returns a failure before the faulty code is reached. Then I tried to login as debian-sys-maint and some other users that do have passwords, and it still did not work.

mjschultz4• 14 years ago

I couldn't get it to reproduce on a VM (VirtualBox) either. I'm wondering if the SSE-optimized version of the glibc doesn't work the same way in a VM as it does on host hardware (i.e. SSE instructions are virtualized to some degree). Since the hardware doesn't support it, the library falls back to a version that won't trigger the bug.

(Again, this is just an unconfirmed theory.)

rominet• 14 years ago

It seems that SSE4 extensions are needed to be vulnerable, otherwise memcmp() is doing classical computations.

So you need a 64 bits system, and be sure that you are not using a virtualisation system which does clear SSSE4 flag in /proc/cpuinfo (VirtualBox does).

Limes102• 14 years ago

<?php while(true) if(mysql_connect("localhost", "root", "password")) exit("connected with password: password");

I am sad to say it worked on my Ubuntu server :(

Security vulnerability in MySQL ubuntu

Related Stories