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:
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 ') SETb2= @b,c3= 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 TABLEt1FIELDS TERMINATED BY ',' ENCLOSED BY '\'' ESCAPED BY '\\' LINES TERMINATED BY '\n' (a1, @b) SETb2= @b,c3`= 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.
In fact, creating the test case for the bug was probably more than 50% of the total work to fix the issue.
So it is nice to get confirmation how important it is to spend the effort to do proper test cases, and how the time spend is worthwhile.
Just wanted to add here that Oracle MySQL 5.5.31 passes the test accept for the case “*** Test truncation of long SET expression in LOAD DATA ***”. I do not think “*** Test truncation of long SET expression in LOAD DATA ***” is a vulnerability and is not related to CVE-2012-4414. So I guess its safe to say that 5.5.31 fixes the vulnerability CVE-2012-4414.
Incorrect truncation is certainly a vulnerability. Why would you say otherwise?
For example, if a string litteral is truncated in the middle. Then a later string litteral will
be parsed as SQL expression.
Hi Kristian,
You are actually right, thank you for correcting me. I am able to cause sql injection due to truncation, I have opened a new bug: http://bugs.mysql.com/bug.php?id=69124 and also on launchpad because Oracle would soon mark that one as private: https://bugs.launchpad.net/mysql-server/+bug/1175519
Ovais –
It seems Oracle attempt to fix it again in 5.5.33. Would you be willing to test for rpl_mdev382 and #69124?
Laurynas,
It seems this time its completely fixed in 5.5.33