Remote hole, DoS in MySQL

Wee writes "I just saw two pretty nasty vulnerabilities in MySQL were announced today by a German company called e-matters. From the annoucenment: "We have discovered two flaws within the MySQL server that can be used by any MySQL user to crash the server. Furthermore one of the flaws can be used to bypass the MySQL password check or to execute arbitrary code with the privileges of the user running mysqld. We have also discovered an arbitrary size heap overflow within the mysql client library and another vulnerability that allows to write '\0' to any memory address. Both flaws could allow DOS attacks against or arbitrary code execution within anything linked against libmysqlclient." Version 3.23.54 fixes the issues in 3.x. I couldn't find a patched version for the 4.0 beta."

Comments

announce@lists.mysql.com

[mnordstr]

Hi,

MySQL 3.23.54, a new version of the world's most popular Open Source
Database, has been released. It is now available in source and binary
form for a number of platforms from our download pages at
http://www.mysql.com/downloads/ and mirror sites.

This is a bugfix release for the current stable tree.

Apart from fixing several bugs, this release also resolves multiple
security vulnerabilities that have been found and reported to us by Stefan
Esser from e-matters GmbH, Germany. You can read the full text of Stefans
advisory here:

http://security.e-matters.de/advisories/042002.h tm l

We are very grateful for his help in spotting and reporting this problem
to us.

As these vulnerabilities can be exploited from a remote attacker to crash
the MySQL server or to execute arbitrary code with the privileges of the
user running the MySQL server, we strongly advise all users to upgrade to
this version.

MySQL 4.0 is also affected by this problem - we will provide updated
packages for this version as soon as possible, too. The required fixes
have already been applied to our public BitKeeper source repositories as
well.

Re:Hold on ...

[Anonymous Coward]

The distributors got the Patch from MySQL-AB several days before yesterday.

risk assessment

[ubiquitin]

So what are the risks involved with not patching your MySQL install ASAP? Should we expect script kiddies to have exploits in their hands in days, weeks, months?

The two flaws in the MySQL server involve TABLE_DUMP and CHANGE_USER, neither of which are typically done regularly, unless you're using dump to backup your db. Interesting that anything that is linked against libmysql is potentially vulnerable to the read_rows Overflow. This means that PHP/Apache/Perl andthere the OS could in theory be exploited this way, though the attacker would have to have some pretty generous write access to the database first. Both client vulnerabilities demand that you feed data into rows that your client is requesting.

The most interesting part of this, by far is the final comment: "Finally it must be mentioned that an attacker can of course use a combination of the described attacks to break into a system or to get access to privileges he normaly does not own. f.e. it is possible for a local user to crash the server with the COM_TABLE_DUMP bug (if he cannot takeover the root account with the COM_CHANGE_USER bug) and then bind a fake server to the MySQL port 3306. And with a fake server he can exploit the libmysqlclient overflow. Another scenario would be an attacker that tries to exploit his favourite mod_scripting language to takeover the webserver by connecting to an external fake server... "

My two cents? Man-in-the-middle attacks are pretty damned hard to pull off, even when the stakes are high and you've got the most skilled cracker interested. Keep current on MySQL releases on a quarterly basis and you should be OK. YMMV

Re:risk assessment

[drinkypoo]

You know, there are people out there who could put together an exploit for so quick that it would make you crap yourself to see it. All it requires is a working knowledge of assembler and an understanding of OS internals. Modern systems are pretty complex but definitely not beyond the realm of understanding.

Of course if he CAN take over the root account then you're screwed any way you go... What I find telling is that the best way to pull off an attack is to do it locally, so once again you will have trouble getting in remotely. We hope. You can probably crash the system remotely pretty reliably, but should have trouble rooting it. That's a major annoyance and could cost you money (though if I had anything that demanded guaranteed uptime, mysql would be an option I considered sometime after writing my own RDBMS) but at least does not open you to other attacks.

bind on '127.0.0.1' only

[Kunta Kinte]

As a precaution...

If you can get away with it, which is true for many people, bind only on local loopback address. Add the '--bind-address=127.0.0.1' in your mysqld startup script, eg. /etc/init.d/mysqld

This causes mysql to only allow connections from the local machine. Eg. if you have apache and mysql running on the same physical computer, and you always use 'localhost' or '127.0.0.1' in your scripts. Not only is it faster ( marginally, I guess ) but it's slightly more secure as well.

Wrong for many O/S platforms.

[TheLink]

Many O/Ses have weak end host bindings.

Which means that any of the IP addresses existing on the host can be reached from any interface on the host even if IP forwarding is off.

This means that if the attacker is on the same LAN they can hit your 127.0.0.1 (or from other networks if 127.0.0.1 is routed to your box via other routers for some unusual reason).

This is true for at least some versions of Linux. True for FreeBSD and many other Unixes. Does not appear to be true for NT/Windows 9x (if it works it means IP forwarding is on).

How to test:
Let Target=A with service listening on 127.0.0.1. No firewalling on A.

Attacker using B disables 127.0.0.1 on B. Sets up static route to 127.0.0.1 via A.

Attacker can now ping/scan A's 127.0.0.1.

You may not be able to test this on some versions of Linux because even if you bring down/ delete the 127.0.0.1 interface it seems to stay hardwired - the packets don't leave the machine. I got this sort of thing to work in the days of Linux 2.0.x. Seems 2.4 is weak end, dunno about 2.2 (seems not to be but some reports say otherwise).

Try it from a cisco router - they don't come with 127.0.0.1 by default.