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

Hold on ...

[The Whinger]

Whilst it is good that we are made aware of these things, and that e-matters waited for MySQL to release a patched version, it would have been nice if they had waited for the common distributions to catch up aswell.

After all - these bugs are pretty serious.

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:this is how i crashed mySQL server

[Mark Round]

"I was writing a complex WHERE clause with multiple ANDs and ORs and I forgot to put the parentheses around OR statements, and that crashed the whole mysqld."

It was like "bleep bleep bleep bleep bleep". It was a really good query. It was like... a bummer.

Re:MySQL vs PostgreSQL

[bovinewasteproduct]

Yeah...

Got money for the hotbackups? They cost.

How about working FKs? I mean if I can drop an entire table that FKs pointing it, not much intergerity is there?
On a different note, has anyone done a decent set of benchmarks comparing MySQL with transactions to PostgreSQL? That would be nice to see.

BWP

Wow.

[budalite]

As a CSE student, (albeit one that is generally twice the age of most of his fellow students) I am really looking forward to the day in my programming where my mistakes don't show up until way, way after the final grades are published.

Not on front page?

[Alizarin Erythrosin]

Seeing as how there may be a number of /. readers who might not catch this story but probably should know about it, why isn't it on the front page?

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.

not as bad as it seems...

[smartfart]

Unless I'm misunderstanding this, these are local exploits only. No one can use these bugs unless he has a valid mysql account on the server in question. These vulnerabilities cannot be used by an external attacker (a website user, for example) to h4x0r the box.

In other words, my servers are not vulnerable. No one else but me has accounts on my boxen. Only a production box (a shell box doing web hosting, for example) where you have untrusted users would be vulnerable.

I'll update my box just as soon as my distro has a patch available, sure, but this event is a non-issue for me (this time).

It's important for some folks...

[Ironica]

I just put in a support ticket with my hosting company, after checking the version of MySQL they're running (3.23.53a). It's virtual hosting with many people all on the same server, and most users have MySQL database access.

So if you are running your own server and have the option of closing it off, yeah, this doesn't matter... but that's not the whole world.

Re:Hot Backups

[gregfortune]

Don't you read your own links? What part of "InnoDB Hot Backup is a non-free additional tool which is not included in the standard MySQL distribution" is unclear to you?

I honestly missed that one :( Although I haven't researched it much, it does sound like the new stuff coming in 4.0 is really cool though. Also, like I mentioned, replication might be a very good solution...

In reply to the foreign key and constraints discussion, it happens to be built into my schema. The schemas I'm creating now create type/size/regex match/etc contraints that get compiled into the program automagically. Another developer and myself have created an object to relational mapping compiler that will translate our "nifty" schema into an object based wrapper over the database. Anyone using the wrapper can be guarenteed that contraints will be enforced, etc. Also, things like foreign key contraints are handle automatically or subclassed for tricky relationships.

In addition, I hate seeing error messages come back from the db. If I can handle all the errors client side, clean data is the *only* thing that gets submitted. I know it's not the accepted way of doing things, but it works very well.

Does MySQL have support for cell constraints like limiting an integer field to a value between 15 and 90 or making sure that a text field has at least seven characters or matches a valid social security number?

I honestly don't know as I haven't needed or wanted it. See above.

This might lead me to believe that support exists though... FOREIGN KEY is ignored, but I think CHECK included and executed...

or [CONSTRAINT symbol] FOREIGN KEY index_name (index_col_name,...)
[reference_definition]
or CHECK (expr)

Another benefit of what I'm doing allows me to quickly port my apps to other databases. Once the layer for Postgres is created in the compiler, I just recompile on the schema, and boom - I have a object layer for a postgres database based on my cool schema in C++, Python, Java, and PHP (assuming the layers for those languages are present in the compiler). All in all, I should be able to write the backend for a company's point of sale GUI *and* their inventory website in a single schema definition.