Slashdot Mirror
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."
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.
Well, now I have a really good reason to switch to postgres...
And the mandatory communist comment: in Soviet Russia, mysql finds holes in YOU!
Hi,
h tm l
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.
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.
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. If anyone wants to see the query, let me know. Worked fine after I added the parentheses.
Consensus is good, but informed dictatorship is better
If MySQL was a real database, like PostgreSQL, you could just roll-back the DOS and be back up and running. ;)
The last thing I would ever want on my K-RAD 31337
Sun Box is a stupid program that will turn my Sun Box
into a crappy DOS box. I hate DOS! I hate windows too.
How come this is not on the front page? Every time there's a small Javascript bug in IE that could possibly change your desktop background colour if you bought your PC in 1996 and your name is Jack or something absurd like that, it gets on the front page. THIS is a very serious set of vulnerabilities, why the hell is it not on the front page?
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.
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?
There are only 10 kinds of people in this world... those who understand binary and those who don't
hooray! Bugs like this prove that the open source model works! After all, many eyes make all bugs shallow. Imagine if this was a Microsoft bug. Fortunately, it was an open source bug, so we can be guaranteed that eventually it will be found and fixed, and maybe your favorite distro will update it so we don't have to bother compiling it ourselves. 3 cheers for open source!
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
http://tinyurl.com/4ny52
Namely, by using linux and MySQL, they guarantee that they boxes will go down faster than Hemos in the men's room of a truck stop, thereby preventing [cr|h]ackers from breaking in.
And here is Your Asshole
He didn't say it didn't exist. He said that it costs money and doesn't come with the main distribution.
Precisely where it shouldn't need to be. You should be able to make a database schema, populate it with data, and know that your data is safe and consistent. Any bad db admin can muck up a schema, but MySQL prevents the good DB admins from doing their job properly.
It is rare that any non-trivial application has only one developer or cohesive group. Database schemas are usually designed by a single person or core group. Can you assert that everyone you work with will clean the user input correctly or work delete a record that another record depends upon? If you design your schema correctly, the DELETE either fails or deletes all of the records that relate to it depending on what data model you choose. An INSERT, UPDATE, and DROP is similarly constrained -- and all or nothing affair with no ambiguities in between.
Your app code can have some checks. Too many checks never hurts quite as much as too few. With PostgreSQL, SAP DB, Oracle, MS SQL, Sybase, DB2, etc., the database is a valid last line of defense against invalid data. They can be made to NOT ALLOW bad data to enter or become bad after it's in. This is the default behavior and not a special set of tables you choose when you download the "Max" version.
If your data is important enough to store, it's important enough to protect. If integrity doesn't matter as much, if your data isn't that important, just use a flat file -- it's much faster for reads and caches well. Or you could put SQUID in front of your web app in which case the database needs to be just fast enough...
Now then, a question: 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? This is not flamebait; I don't know, and I'm curious. I don't see mention of them on a search of "constraint" on the mysql.com. I certainly hope it does or I'll have a new thing to bitch about with MySQL.
- I don't need to go outside, my CRT tan'll do me just fine.
This is something that affects tons of us. I have MySQL installed both under linux and Windows XP... Does this flaw exist on all platforms?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Unforunately, if you compile your own with RH8 (or at least on my machine) the new version chokes and dies... big time. Seems there may be an issue with the glibc on this distro?
It's not a Microsoft product.
Despite the fact that there are probably more installations of MySql than SQL Server, or something. Ah, who cares. It's not about MS, therefore it's not actually news.
As a precaution...
/etc/init.d/mysqld
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.
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.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
For whatever it's worth, if you're looking for
work in the Beaverton, Oregon area, the
Open Source
Development Lab today posted a req for a
Perl/MySQL developer. They do 100% non-profit,
open source work on the Linux kernel and open
source in general.
Given what databases are I'd only let trusted people access to them. You'd be courting trouble exposing your MySQL/Postgresql/Oracle server to untrusted parties (whether internal or external).
1) Many DBs store important/critical data.
2) Most DBs were never designed for hostile environments. Plus I haven't encountered a situation where you really need to expose DBs to the big bad world.
3) The people writing DBs seldom concentrate on security - they have lots of other things to do.
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.
This is the way security bugs should be dealt with. All praise the Germans who have the decency to report to the developpers first and *then* to the general public.
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).
Need a Linux consultant in New Orleans?
delete from table1, table2 where table1.id=table2.table1_id;
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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.
Don't you wish your girlfriend was a geek like me?
And I already knew that
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I'll tell you what. I'll give you a code snippet and see what you think about it.Hmmm...at first glance, this may seem like a lot of logic to have in your database, but look closer. If someone tries to put in a password less than six characters, it fails. Clients do not have to learn how to use MD5 or how much padding is used in all implementations. This means that anyone, in any applicable query, with any client -- and is authorized to make changes to the database -- who makes an INSERT or UPDATE on the users table will have constraints put upon them. Once you get at least five developers together on a project, the methods for talking to the persistence layer will drift -- perhaps just slightly, but it will drift.
And now hear this: nothing is stopping you from making additional application checks at the client level for data integrity. In fact, it makes sense so that you don't have to make the persistence roundtrip. However, you should not overlook the fact that you cannot put a bad value into my database schema. The database simply won't accept it (I still need to make dictionary checks, but time is short).
But do you see the difference? This isn't about antiquated storage methods (punch cards). This is the difference between your method which shouldn't have bad data if written correctly and my method which absolutely doesn't allow bad data in the database. Period.
There's a difference between being relatively sure that the data in your database is valid and knowing for sure that the data is valid (Yes, yes, I know: backups in case of hardware failures).
The data is the database's responsibility. Moving data here and there, communicating with the user, and all sorts of other logic details are the app layer's responsibility. Here, the database is just making sure the data is clean. That's all. In my earlier example, the database was setting up a timestamp value for caches. The timestamp is data. The timestamp refers to validity of other data. This can go in the database itself. It's not really anyone else's business.
This should be the app layer's responsibility? I have only these counterexamples. SELECT MAX(lastmod) when there are no triggers and functions (see my previous post). Making sure the MD5 implementation is the same for all client libraries in all languages when there are no triggers and functions.
No code is perfect. I'm not advocating that you rely solely on the database. What I'm saying is that the database can be correctly used as a last line of defense for bad data that somehow crept through.
- I don't need to go outside, my CRT tan'll do me just fine.