
Security vulnerability in MySQL ubuntu - mjschultz
http://seclists.org/oss-sec/2012/q2/493
======
tptacek
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_.

~~~
dhx
―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>

~~~
tptacek
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.

~~~
einhverfr
Actually that's exactly what we do with LedgerSMB. The database is the final
enforcer of security matters and the authoritative voice in authentication
(the web app logs into the db with user-supplied credentials). A lot of
traditional middleware functions are pushed into the db (as stored procedures)
where these can be reasonably represented as set operations against the
database. As an ERP application, this means that this includes just about
everything except generating printable invoices or HTML.

This works well. There are some things we are still working on improving, but
it's getting there. Moreover it means multiple clients on multiple codebases
are possible and we don't have to worry as much about the implications of what
happens when someone writes a secondary client to hit the database.

At the same time, we use PostgreSQL, which I have a bit more confidence in
than MySQL. Of course I would still suggest limiting access only to those IP
address ranges where that is necessary.

~~~
iuguy
Oh god you poor man. We took a look at using SMB Ledger (the parent of
LedgerSMB) years back and after peeling back the covers it just looked
horrific both from a security and general code quality perspective. This was
around the time of the fork, and I couldn't help feel that SMB Ledger had it's
work cut out. Hopefully you guys have been able to get through to the other
side.

~~~
einhverfr
Well, here's the status so far.

1) Going to a db-centric security model has allowed us not to trust the SQL-
Ledger code (good thing too).

2) We are refactoring/removing SQL-Ledger code as quickly as possible. As of
1.3 this means payment logic, reconciliation logic, contact management logic
and more. 1.4 will hopefully rip out and replace _all_ search and reporting
functions. It will take us a few more years to get the codebase where we want
it though.

3) The bad thing about bad code is that bad code is contagious. When you spend
a lot of your time debugging bad code it is very hard to write good code. Most
of what we wrote for 1.3 will need to be rewritten again. I am pretty happy
with the code we are writing for 1.4.....

I think we have come through the worst of it. Pace of development is speeding
up which is a good sign and much more of the application is subjected to unit
tests.

As a side note, when we first added unit tests to the number rounding tests
for the code we inherited from SQL-Ledger, there were failures. We replaced
that logic very quickly.

Yeah, it was pretty bad... Now its getting better.

Edit: Also it seems to me the worst never seems so bad when you are in it. I
don't think that I could see how many problems we had from this until I am
here, half way from 1.3 to 1.4, asking why 1.3 took five years to release (we
beat Perl 6 and HURD though, I guess Duke Nukem Forever in fact beat us date-
wise by a couple months).

Looking back at the customers of mine who have had problems, or projects that
went way over budget or took too long because of difficulties here, I can see
how much that hurt us. At the time though, it was just one of those keep
working on it kind of things.

------
tedunangst
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.]

~~~
einhverfr
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.

------
rlpb
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...](https://lists.ubuntu.com/archives/ubuntu-
server/2012-February/006073.html) and
[https://lists.ubuntu.com/archives/ubuntu-
server/2012-Februar...](https://lists.ubuntu.com/archives/ubuntu-
server/2012-February/006129.html) for details.

~~~
ios84dev
What about <http://bugs.mysql.com/>?

------
gyaresu
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

------
captn3m0
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>

~~~
dhx
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?).

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

------
mattbee
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.

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

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

~~~
Negitivefrags
That wasn't how I read it.

It sounds like they were casting the result of a memcmp to a char. A char only
has a range of -128 to 127. The resulting overflow means that an arbitrary
password hash has a 1/255 chance of landing on 0, but you still have to try a
bunch to hit one.

~~~
mike-cardwell
This is incorrect. You do not need to try a different password each time.

------
ushi
_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?

~~~
dangrossman
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
where is the perl one-liner :P?

~~~
mcpherrinm
perl -e 'use DBI; for($i=0;$i<4096;$i++){DBI->connect("dbi:mysql:", "root",
"nope", {PrintError=>0}) and die "Vulnerable!";}'

------
jms
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-...](http://mixeduperic.com/ubuntu/how-to-restrict-phpmyadmin-ip-
address.html)

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

~~~
tedunangst
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
> 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.

~~~
tedunangst
I was at first tempted to complain about useless pedantry, but you're right.
Even if some of us still like to party like it's 1989. I should have said the
real lesson is don't reimplement standard C types, poorly.

------
mmaunder
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.

~~~
Apreche
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.

~~~
mjschultz
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.)

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

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

~~~
darklajid
Maybe.

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

~~~
vladd
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.

------
Limes102
<?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 :(

------
rominet
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).

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

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

Why 1/256?

~~~
jontro
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.

------
gouranga
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).

~~~
viraptor
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.

~~~
gouranga
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...

~~~
pgeorgi
except that they try to optimize randomness in security libraries every now
and then.

~~~
gouranga
Any more details? Not had any problems on that side of things yet.

~~~
0x0
<http://digitaloffense.net/tools/debian-openssl/>

~~~
gouranga
Thanks for this - interesting read :)

------
dfc
Is the bug limited to ubuntu?

~~~
tedunangst
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.

------
jontas
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.

~~~
drivebyacct2
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
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).

