This doesn't seem very threatening at all. If you're not already running services with strict file permissions this is the least of your worries.
edit: appears shell access isn't required to upload the malicious library, but you still need valid MySQL creds. Just because a SQLi might be there doesn't mean you can upgrade this to "remote code execution". That's just chaining vulns together; it doesn't magically upgrade the severity of this.
Given MySQL creds and a (fairly common) file write primitive (file upload functionality, log injection, etc) that in itself should not qualify as a vulnerability, you can execute remote code on the server with just this vulnerability.
I think RCE is a fair description here.
This is an important issue to consider, but it has been WAY overblown as presented here.
To be perferctly clear: if you are running mysql in your production stack, you are most likely NOT affected by this whole ordeal at all. Now, with the initial panick blown off, please read the article and assess wether you are one of the few affected users out there or not (in short: only worry if you have regular users with the FILE privilege enabled).
Spreading FUD doesn't help anybody...
When... did I say that? I said: a file write primitive on a server is fairly common. e.g. a PHP web app that lets you upload a file to some directory on the server. An attacker could use such a feature to upload a .so file to load into mysqld.
I'm just arguing that the title of RCE is accurate here. In a non-trivial amount of configurations you can abuse this vulnerability to remotely compromise a machine you otherwise couldn't get a shell on. Hence RCE.
I can see this leading to RCE in a number of scenarios:
- default/abandoned mysql install with default root creds. If you also have a file write primitive on the server (which IS common in LAMP stacks), now you can get RCE with it.
- mysql install with weak superuser creds that you've bruteforced. If you also have a file write primitive on the server (which IS common in LAMP stacks), now you can get RCE with it.
- db superuser uses the same db password as the app's connection. If you also have a file write primitive on the server (which IS common in LAMP stacks), now you can get RCE with it.
Are these super-common scenarios? No, but they are most certainly out there. Yes, you can say "this obvious mitigation would have prevented it", but that doesn't change the facts. You can abuse this in some set of circumstances to get RCE, so "RCE" is an accurate label, and THAT'S ALL I'M SAYING.
It also means that an SQLi vulnerability suddenly becomes a potential remote root shell.
This would be a target for a sql injection exploit and so is remotely exploitable
As a standalone issue I agree with the GP comment - this bug is not a RCE issue, it's privilege escalation.
Some setups serve mysql over tcp/ip, sometimes even on the internet. Maybe you wouldn't trust mysql's ssl usage or username/password auth mechanisms, but they are there, and some people use those features. So this should certainly be considered a remote vulnerability, as long as the exploit can be launched from the client side of a mysql connection.
My reading of this is that it requires either mysql root or `GRANT FILE ON . TO ...` privileges? AFAICT this requires an explicit `GRANT FILE ON . TO ...`; just plain `GRANT ALL ON db.* TO ...` does NOT grant any FILE privileges. I assume an install that doesn't give any users FILE privileges is safe?
mysql> SELECT host, user, File_priv FROM mysql.user WHERE File_priv='Y';
AFAICT exploit chain:
* `GRANT FILE ON . TO ...`
* `SELECT unhex("%s") INTO DUMPFILE '%s'`
* ... clever tricks ...
* mysql root
* service mysql restart
* system root
The mysql security model for FILE privileges described here seems ridiculous. Your security model relies on creating dumpfiles with `chmod 666` permissions, and rejecting config files that are world-writeable? "I fixed the security issue with world-writable dump files" "You just broken our security model!"
Never grant FILE privileges on a production mysql server?
Then you can write
GRANT FILE ON *.* TO
> No official patches or mitigations are available at this time from [Oracle].
> The vulnerabilities were patched by PerconaDB and MariaDB vendors by the end of 30th of August.
Looking at the PoC, it seems possible to overwrite any file that the MySQL user (or whichever user MySQL runs as) can write to.
In the PoC, they overwrite /etc/my.cnf, which is often advised to be chown'ed to mysql, making this possible (normally files in /etc are only root-writable). The new version loads a malicious shared library. This means that you should have made the mistake of making it mysql-writable (on top of others having SQL access to the server in the first place). This is not the case on my Ubuntu 14.04 LTS server, so anyone running that without weird modifications is probably safe as well.
Some wrapper script is mentioned which runs as root (while mysql itself runs as a separate user), which would apparently make it possible to get root on the server. I guess that's another requirement for real impact, but the first 2 compromise your MySQL server already so that's serious enough.
Edit: Updated post according to comment from jstanley. Thanks!
> People that can run queries on your MySQL as a user that has FILE privileges, either by legit access or via an SQL-injection vulnerability, can execute commands that might root your server.
This may seem nitpicky, but it makes a world of difference. For instance, none of the (many) shared hosting providers (godaddy et. al.) nor solutions (plesk, cpanel, etc.) I know of give FILE permissions to SQL users at all.
In fact, the shoddy way to create users is through the "GRANT ALL PRIVILEGES ON mydb.* TO 'myuser'@'%'" command, which does not grant FILE privileges to that user.
Taking this into account, another possible summary is:
If you explicitly created mysql users with the FILE privilege or you are using the root user for day-to-day operations, you may get your server rooted. Stop doing that. Otherwise nothing to see for you here, just move on and install whatever security updates are issued by your distro-de-jour.
Not at all. I was trying to figure out what it was about in a rush (I was leaving home, but RCE on MySQL was high prio for me) and while figuring it out, thought I might write it down for others. It's a lot of info left and right throughout the article, so I might not have put it together correctly. Thanks for the correction!
If you can overwrite any file the MySQL user can write, does that means you can place a malicious library on the system, or must it be loaded from somewhere in the ld search path?
Causing it to try and load a random .so would probably crash the DB. Since this is in the config file, it would restart and immediately crash.
This would be an effective Denial of Service attack.
As for 3) I guess this just something to check for if you find SQL injection vulnerabilities in your application.
But that shouldn't dissuade one from taking some preventive measures, e.g. making sure that unnecessary FILE privileges are revoked from accounts and/or making sure that my.cnf is owned by root and only writable by root. Also, as the CVE mentions, do remember that a my.cnf in /var/db/mysql (or /var/lib/mysql for Linux) will override settings in other locations. Touching it as root with an appropriate flag mask should plug that hole too.
An updated mysql package will be soon be available of course.
It's interesting to see how many people look at this and react "Whoa! Shell access!" or "Whoa! Malicious shared library injection!", and how few have commented on the fact (almost treated as a minor sideline) that one vector for the exploit involves setting up database triggers that run with SUPER privileges.
"Whoa! Attackers (with FILE privilege) can alter your purchase orders and invoices, steal your contacts and confidential customer account information, change inventory records, and forge identities." No shell access or shared libraries involved.
But that's been known as CVE-2012-5613 for some time. (-:
Don't grant more permissions to an application than they absolutely need.
Exploiting this remotely requires the ability to change logging, an administrative command which should not be available to anything but your devops tools and your operation engineers. It also requires the write bit to be set on a configuration file; MySQL does not need to be able to write to its configuration file to run. Again, the only thing writing to the file should be your devops tooling.
Follow this simple idea, and you'll avoid a lot of CVEs.
As for the LD_PRELOAD vulnerability, this has been fairly well known for many years (I watched a colleague demonstrate this at a MySQL conference back in 2013), and it affects quite a few more programs than just MySQL.
According to the docs, this has been configured to '/var/lib/mysql-files' by default for most distribution packages since 5.7.6. Still worth updating though, in case CVE-2006-6663 bypasses that.
For Postgres at least you are not the god-like DBA, so I just trust they have all bases covered (or at least more resources than I have for keeping everything safe).
(Part of) the problem is that it is run at all. Don't be confused into thinking that this is a Debian problem, moreover, just because the problem happened to be demonstrated on Debian Linux. Debian isn't the only system still running mysqld_safe.
Debian 8 packages up mysql 5.5 with only a van Smoorenburg rc script, no systemd units.
Debian 8 only has mysql 5.6 available through backports. That has a systemd service unit, written in 2014 by Akhil Mohan of Oracle. That service unit invokes mysqld_safe, though, in classic systemd House of Horror fashion.
Apparently, Red Hat Enterprise Linux 7 has no systemd unit files for mysql 5.6, either, and still uses mysqld_safe.
The whole thing is a bit overblown, given that application users at any security-minded company won't have either of these two privileges either.
Seriously though, almost every vulnerability that gets disclosed can have the "this is all overblown, and any security minded company won't have this problem", and yet we are all dealing with the long tail of malicious software and services hosted on vulnerable infrastructure...
* Don't give SUPER or FILE privs to your application's mysql user
* Don't allow mysql to accept connections from the public internet
* Avoid SQL injection through use of bind variables
This is pretty elementary stuff, and just doing any 2 of the 3 above will prevent this exploit from being usable. (unless the attacker has SSH access to your hosts, but in that case, you should already consider your entire environment to be compromised.)
Like, at all?