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."

4 of 68 comments (clear)

  1. Re:MySQL vs PostgreSQL by bovinewasteproduct · · Score: 3, Interesting

    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

  2. not as bad as it seems... by smartfart · · Score: 4, Interesting
    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).

  3. It's important for some folks... by Ironica · · Score: 3, Interesting

    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?
  4. Re:Hot Backups by gregfortune · · Score: 3, Interesting

    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.