CVE-2012-4414 strikes back in MySQL 5.5.29 (and what we’re doing in Percona Server 5.5.29)

PREVIOUS POST
NEXT POST

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 ') SET b2= @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 TABLE t1 FIELDS TERMINATED BY ',' ENCLOSED BY '\'' ESCAPED BY '\\' LINES TERMINATED BY '\n' (a1, @b) SET b2= @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.

PREVIOUS POST
NEXT POST

Comments

  1. says

    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.

  2. says

    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.

  3. says

    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.

  4. Laurynas Biveinis says

    Ovais –

    It seems Oracle attempt to fix it again in 5.5.33. Would you be willing to test for rpl_mdev382 and #69124?

Leave a Reply

Your email address will not be published. Required fields are marked *