Home |  MySQL Buzz |  FAQ |  Feeds |  Submit your blog feed |  Feedback |  Archive |  Aggregate feed RSS 2.0 English Deutsch Español Français Italiano 日本語 Русский Português 中文
CVE-2012-4414 strikes back in MySQL 5.5.29 (and what we’re doing in Percona Server 5.5.29)
+4 Vote Up -0 Vote Down

In preparing Percona Server 5.5.29 (not yet released, but soon), I filed MySQL bug 68045 (is marked private as it’s a security bug). This bug is in relation to the Oracle fix for CVE-2012-4414 and a problem I found with it. The MariaDB fix (which we incorporated into Percona Server 5.5.28-29.3) is not affected.

When the MariaDB team fixed CVE-2012-4414 they created a test case named rpl_mdev382.test which can be found in MariaDB and Percona Server sources. It is named after the designation in their bug database, MDEV-382.  Having a public test case for such a bug is very important, it means that anyone can verify if their MySQL server is vulnerable, after all, many people run their own patches. It allows Linux distributions to check that what they ship is okay or not which typically includes a few patches on top of the base distribution.

Sadly, Oracle did not run the MariaDB test against their own fix for this bug. While there are many reasons why Oracle does not take patches (that no user cares about), having Oracle re-implement bug fixes is really just a waste of Oracle time and money rather than anybody else’s. However, in this instance, even though they didn’t publish a test case (presumably they have one internally), we still have a test case courtesy of the MariaDB developers.

I used the MariaDB test case against my branch that updated Percona Server to be based on MySQL 5.5.29 and I noticed it failed. I then tried the test case on stock MySQL 5.5.29 (the Oracle provided binaries); it also failed.

Basically, the following snippet from rpl_mdev382:

eval LOAD DATA INFILE '$MYSQLTEST_VARDIR/tmp/f''le.txt' INTO TABLE `t``1`
  FIELDS TERMINATED BY ',' ESCAPED BY '\\\\' ENCLOSED BY ''''
  LINES TERMINATED BY '\\n'
  (`a``1`, @`b```) SET `b``2` = @`b```, `c``3` = concat('|', "b""a'z", "!");

becomes this error in the slave:

Last_Error Error 'You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '`) SET `b``2`= @`b```, `c``3`= concat('|', "b""a'z", "!")' at line 1' on query. Default database: 'db1`; SELECT 'oops!''. Query: 'LOAD DATA INFILE '../../tmp/SQL_LOAD-2-1-1.data' INTO TABLE `t``1` FIELDS TERMINATED BY ',' ENCLOSED BY '\'' ESCAPED BY '\\' LINES TERMINATED BY '\n' (`a``1`, @b`) SET `b``2`= @`b```, `c``3`= concat('|', "b""a'z", "!")'

Which (check it if you like), means that the Oracle fix is incorrect and ruins quoting in this situation, which then breaks statement based replication. Users of MariaDB and Percona Server are not affected, only MySQL 5.5.29 users are.

For Percona Server 5.5.29, we are planning to just keep the MariaDB based fix. Once Oracle fixes this bug, we may re-evaluate that (in order to keep a smaller delta from MySQL) but for our next release, we would prefer not to expose our users to a regression.

The post CVE-2012-4414 strikes back in MySQL 5.5.29 (and what we’re doing in Percona Server 5.5.29) appeared first on MySQL Performance Blog.

Votes:

You must be logged in with a MySQL account to vote on Planet MySQL entries. More information on PlanetMySQL voting.

Planet MySQL © 1995, 2014, Oracle Corporation and/or its affiliates   Legal Policies | Your Privacy Rights | Terms of Use

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.