Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security

Remote hole, DoS in MySQL 68

Posted by michael from the whoops dept.
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."
This discussion has been archived. No new comments can be posted.

Remote hole, DoS in MySQL More

Remote hole, DoS in MySQL

Comments Filter:

  • Hold on ... (Score:4, Insightful)

    by The Whinger ( 255233 ) on Friday December 13, 2002 @11:21AM (#4880605) Homepage
    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.

    • Re:Hold on ... (Score:1, Informative)

      by Anonymous Coward
      The distributors got the Patch from MySQL-AB several days before yesterday.
    • Ahhh - okay ... another good reason to roll-your-own.

    • not as bad as it seems... (Score:4, Interesting)

      by smartfart ( 215944 ) <joey AT joeykelly DOT net> on Saturday December 14, 2002 @07:25PM (#4889093) Homepage Journal
      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).

  • Well, now I have a really good reason to switch to postgres [postgresql.org]...
    And the mandatory communist comment: in Soviet Russia, mysql finds holes in YOU!
    • So what makes postgres so great? All programs have holes, and the ones that claim they don't are lying.
      Come on people, open source holes have overtaken Microsoft's now, but this is a good thing. If they're being found they're being closed. This ism a good thing for the community at large.
    • 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.

  • announce@lists.mysql.com (Score:5, Informative)

    by mnordstr ( 472213 ) on Friday December 13, 2002 @11:34AM (#4880721) Journal
    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.
  • 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.
  • If MySQL was a real database, like PostgreSQL, you could just roll-back the DOS and be back up and running. ;)
    • I assume this is just a troll, but I'll bite. MySQL has supported transactions [mysql.com] for quick a while. Please save me some time and do your research...
      • 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
        • Got money for the hotbackups? They cost.
          ??? 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...
          • 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?

            He didn't say it didn't exist. He said that it costs money and doesn't come with the main distribution.

            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.

            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)

              by gregfortune ( 313889 )
              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.
              • 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.

                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 .Net framework. Does anyone but you know how to use this persistence layer? Is it distributable?
                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.

                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:
                RAISE EXCEPTION "The password must be at least six characters!"
                Seems to me like a friendly and useful database error message to me.
                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...

                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.

          • 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!

    • Not a troll, just a lame joke.

  • Wow. (Score:3, Funny)

    by budalite ( 454527 ) on Friday December 13, 2002 @02:39PM (#4882320)
    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? (Score:5, Insightful)

    by Alizarin Erythrosin ( 457981 ) on Friday December 13, 2002 @03:26PM (#4882723)
    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?
    • Because it's not a MS security hole....

      Seriously though I would have thought this should have been on the front page too. It certainly seems news worthy enough.
    • (only one to go till 5 anyway)

      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)

    by ubiquitin ( 28396 ) on Friday December 13, 2002 @05:50PM (#4883682) Homepage Journal
    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 (Score:3, Informative)

      by drinkypoo ( 153816 )
      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.

    • The point is not how hard you think it is to do an exploit, the point is that there is a hole to be exploited. Holes should be patched. Period.
  • 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?

  • bind on '127.0.0.1' only (Score:3, Informative)

    by Kunta Kinte ( 323399 ) on Saturday December 14, 2002 @02:22AM (#4885725) Journal
    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. (Score:4, Informative)

      by TheLink ( 130905 ) on Saturday December 14, 2002 @11:01AM (#4886883) Journal
      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.

  • It's important for some folks... (Score:3, Interesting)

    by Ironica ( 124657 ) <pixel@bo o n d o c k.org> on Sunday December 15, 2002 @03:39PM (#4892959) Journal
    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.

Slashdot Top Deals

"May your future be limited only by your dreams." -- Christa McAuliffe

Close