Remote hole, DoS in MySQL 68
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."
Hold on ... (Score:4, Insightful)
After all - these bugs are pretty serious.
Re:Hold on ... (Score:1, Informative)
Re:Hold on ... (Score:1)
Re:Hold on ... (Score:1)
I meant package
not as bad as it seems... (Score:4, Interesting)
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).
I'm switching to postgres (Score:2, Funny)
And the mandatory communist comment: in Soviet Russia, mysql finds holes in YOU!
Re: (Score:1)
Re:I'm switching to postgres (Score:1, Insightful)
Re:I'm switching to postgres (Score:1)
Re:I'm switching to postgres (Score:2)
Re:I'm switching to postgres (Score:1)
What might you consider slightly complicated SQL?
Triggers, foreign keys, stored procedures, fast ACID-compliance, SQL95-compliance, no bullshit hacks like "*" to increment...
cascaded deletes (Score:2)
Re:cascaded deletes (Score:2)
The multi table delete format is supported starting from MySQL 4.0.0.
There is no MySQL 4.0.0 yet (Score:2)
Re:I'm switching to postgres (Score:1)
Bad reason to switch. (Score:2)
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.
announce@lists.mysql.com (Score:5, Informative)
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.
this is how i crashed mySQL server (Score:2)
Re:this is how i crashed mySQL server (Score:1)
Neo-stonebeat.org: "I know.... how to crash mysqld."
HaloZero: "Show me."
[poof]A complex computer construct appears.
Re:this is how i crashed mySQL server (Score:5, Funny)
It was like "bleep bleep bleep bleep bleep". It was a really good query. It was like... a bummer.
MySQL vs PostgreSQL (Score:2, Funny)
Re:MySQL vs PostgreSQL (Score:2)
Re:MySQL vs PostgreSQL (Score:3, Interesting)
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
Re:MySQL vs PostgreSQL (Score:2)
??? I'm not sure if I understand your complaint. Online backup is already available and much improved support is coming in 4.0/4.x. See here [mysql.com] and here [mysql.com] In addition, replication [mysql.com] is not a bad way to build some fault tolerance into your system. I'm not claiming that any of these features are perfect or that they fit your exact needs. I'm merely pointing out that they exist.
How about working FKs? I mean if I can drop an entire table that FKs pointing it, not much intergerity is there?
Don't know what to tell you there. I know foreign key support is planned, but I'm handling all my data integrity inside my apps. InnoDB tables are supposed to support foriegn keys, but again, I don't know how complete the support is as I haven't used them...
On a different note, has anyone done a decent set of benchmarks comparing MySQL with transactions to PostgreSQL? That would be nice to see.
Yes, but I don't see any that don't look biased towards MySQL...
Hot Backups (Score:2)
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.
Re:Hot Backups (Score:3, Interesting)
I honestly missed that one
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.
Re:Hot Backups (Score:2)
Every other database has the philosophy that bad data is not allowed. Period. What happens when you leave your company -- or you're on vacation -- and the new guy who is familiar with MySQL just decides to whip up a script to perform some query on the database?
I'm not trying to say that what you have doesn't work for you. I'm saying that what you have is vulnerable to circumvention without malice.
As a side note, your engine sounds conspicuously like EJBs and the
Ummm...so? Java can catch SQL Exceptions, C can check error codes, Perl can trap any error message with eval. If you are seeing messages from the database when you didn't intend to, you have done something wrong. Don't blame the database engine. This is an app layer bug.
In other news, I raise exceptions in stored procedures all of the time. Those error messages are clear, concise English phrases that I specify.
For example, I have this statement in one of those stored procedures called from an insert and update trigger:Seems to me like a friendly and useful database error message to me.
This is a good thing, but it doesn't justify the use of MySQL; It only justifies the use of your object layer. If you took out MySQL support, you could have triggers, stored procedures, views, advanced constraints, custom data types, rules, etc. when you moved from database to database. Why limit your options with MySQL? If it's so that you can support everything, do you also support comma-separated-value files through ODBC as well, or would that be silly? There is always a lower level of functionality.
Just as you wouldn't waste your time with CSV over ODBC because of limited functionality and brittleness, why do you waste your time with MySQL?
Is MySQL faster for SELECTs? Sure. But what people don't seem to get is that with all of those "useless" features of real RDBMSs, you can make a schema that enforces correct data (reducing processing time and complexity in the app layer), and you can have triggers and rules modify cache tables that give commonly used data and/or last-modified info. I don't care how fast MySQL has been or wil be; The fastest queries will always be the ones that you don't have to make as many times. The best use of a database is usually where you don't have to send as much data over the wire in communication.
Example: You have dynamic content, but the interval between updates is large enough to justify caching.
Using MySQL, you would have to insert the data with a timestamp (don't forget the index on the column!), make a query for the newest timestamp using a MAX aggregate, check the timestamp against the cache timestamp, make the real query if the timestamp's newer than cache, get the results back, and update the cache timestamp. Note that you would have to remember to update an entry's timestamp in every part of the code that would ever make updates the table(s). And of course, this is only a single table for granularity. For joins, you would have to do multiple max timestamp checks.
With the others, you would make a cache table with just one timestamp entry for the query -- no matter how many tables it spanned. Note that you have already saved rows*sizeof(timestamp)*tables in space over MySQL as a bonus, so your tables are more likely to fit into physical RAM for greater performance. Next you would write an insert and update trigger for the tables that would update this cache timestamp value on changes. The logic for this is located in only one place: the source of the data.
Using a database other than MySQL, you would insert the data without a timestamp (handled internally by the database), SELECT on the very small cache table for one entry, compare against your local cache timestamp, make the real query if the timestamp's newer than cache, get the results back, and update your app cache.
I don't care how fast you think MySQL is. It will never be able to make repeated "SELECT MAX(modified) FROM bigtable;" calls faster than repeated "SELECT modified FROM cache WHERE key = 'somedatamodel';" The overhead of updating a single or small number of rows to change a timestamp value is lost in the overall insert or update processing (no index and it's update overhead is necessary for that small a table). And any client, custom object model or no, will work.
THIS is why I have a problem with MySQL. It isn't some esoteric feature. I want to scale. No database benchmark will adequately demonstrate this when all it is comparing is SELECT and INSERT performance. I want to set up my database and go -- not constantly tweak my app layer to fudge a few milliseconds of processing time less or sacrifice data dynamism. It's not that the other databases are more feature-rich; MySQL is feature-poor. Will it work for small installations? Sure, but so will any other database out there. The small problems are easy. It's the big problems -- or the small problems that steadily grow -- that demand our attention.
If you want to use it, that's your decision. But don't delude yourself or others into thinking it is the optimum solution.
Hahahaha!!! (Score:2)
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.
Re:Hot Backups (Score:2)
Re: separating functionality
I do separate functionality. My logic layer and my presentation layer (they are separate for you too right?) can make checks for data validity as well. In fact, I recommend it. It hurts far less to check a value twice than to forget to check it even once.
Ummm...when did I say anything about country lists and sales prices? Think carefully. Check my post. I talk about data: the cleanliness of that data, the integrity of that data, the status of that data, etc. I never talk about doing advanced logic. Then again, why wouldn't you save a list of countries (and the most up to date info on exchange rates) in the database? Or were you talking about user interface translations (which I wasn't). Why wouldn't you have sale prices for items sold during sales? You would keep that info wouldn't you? You would want to know that the item sold for $12 instead of $18 wouldn't you?
Side note for those who didn't get the memo yet: database transactions != financial transactions. Database transactions can be used to facilitate financial transactions, but they are not and have never been the same.
Re:MySQL vs PostgreSQL (Score:1)
I know foreign key support is planned, but I'm handling all my data integrity inside my apps.
And with that, we discover that gregfortune is not a database admin. By a long shot. It is simply not possible to achieve true ACID conformance and have your data integrity outside the database!
Re:MySQL vs PostgreSQL (Score:1)
Re:What you say? (Score:2)
Besides by the time you could even touch MySQL through my firewall you'd more likely have moved on to easier prey. IE is usually used by sheep that don't know when security problems exist, don't know how to fix them, and are usually not told by their software provider or given a way to make that fix until way to late.
Even if you did get inside my database you couldn't get into the rest of my OS because I am not stupid enough to run MySQL as root. With Windows/IE a minor bug can trash the entire system. Users are also less likely to make frequent backups.
However... I would not mind all major security problems such as this making the frontpage. To alert people that don't follow their email warnings close enough.
Re:What you say? (Score:2)
Wow. (Score:3, Funny)
Not on front page? (Score:5, Insightful)
Re:Not on front page? (Score:1)
Seriously though I would have thought this should have been on the front page too. It certainly seems news worthy enough.
MOD THIS UP (Score:2)
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?
risk assessment (Score:5, Informative)
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 (Score:3, Informative)
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.
Re:risk assessment (Score:1)
Self-compile blues (Score:2)
bind on '127.0.0.1' only (Score:3, Informative)
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.
Wrong for many O/S platforms. (Score:4, Informative)
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.
Re:Wrong for many O/S platforms. (Score:1)
It's important for some folks... (Score:3, Interesting)
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.