
MySQL Remote Root Code Execution/Privilege Escalation Exploit - dawid_golunski
http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html
======
feld
I think this is poorly framed as RCE when it's just privilege escalation. The
user already needs MySQL login access, shell access, and the ability to upload
a malicious library that can be added to LD_PRELOAD through a setting in
my.cnf. They do propose a trick to overwrite my.cnf with a logging function,
but still...

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.

~~~
bechampion
i agree with that .. this isn't remote at all.

~~~
TickleSteve
The point is that it is exploitable from SQL, therefore is also exploitable
from the application that is creating the database.

This would be a target for a sql injection exploit and so _is remotely
exploitable_

~~~
whyleyc
That requires your application to be vulnerable to two types of exploit in
order to pull off RCE - if you are vulnerable to SQLi there are likely a whole
raft of other issues which would give you a remote shell.

As a standalone issue I agree with the GP comment - this bug is not a RCE
issue, it's privilege escalation.

------
terom
EDIT: HN formatting isn't letting me write "asterix dot asterix", it shows up
as " _._ " :(

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

* ... clever tricks ...

* 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?

~~~
ptaipale
Hint: try it as a text after a blank line with two spaces preceding it.
[https://news.ycombinator.com/formatdoc](https://news.ycombinator.com/formatdoc)

Then you can write

    
    
      GRANT FILE ON *.* TO
    

(How to find out? Google.)

------
lucb1e
Summary: people that can run queries on your MySQL server, either by legit
access (shared webhosting or something else) or via an SQL-injection
vulnerability, can execute commands that might root your server.

Vendor response:

> 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!

~~~
kilburn
The more correct summary is:

> 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.

~~~
lucb1e
> This may seem nitpicky

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!

------
aduitsis
For FreeBSD users out there, I would seem that, in the default setting, the
mysqld_safe script is being run as mysql uid by the rc startup script. So by
the time mysqld_safe is invoked, root privileges are already dropped.

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.

~~~
JdeBP
So one can merely get shell access as the unprivileged server process user
rather than as the superuser.

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. (-:

------
rini17
Hm, they say "patched by MariaDB by August 30" but I don't see anything
possibly related here
[https://github.com/MariaDB/server/commits/10.1](https://github.com/MariaDB/server/commits/10.1)
nor in other releases/tags.

~~~
kosinus
Here is the relevant ticket:
[https://jira.mariadb.org/browse/MDEV-10465](https://jira.mariadb.org/browse/MDEV-10465)

~~~
djvdorp
Thanks for linking this here, did somebody also find the relevant reference to
the Percona equivalent of this one?

------
falcolas
IMO, this can be avoided by following one simple operational hygiene concept:

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.

~~~
JdeBP
You are missing a subtlety by referring to "its configuration file" in the
singular. Part of the problem is that there are multiple possible
configuration files, at least one set of which normally does not exist and
lives in the MySQL data directory which is writable by the unprivileged server
user.

------
predakanga
An additional safeguard against this exploit would be using the
`secure_file_priv` option, which restricts the location that queries can write
to.

According to the docs[0], 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.

[0]: [https://dev.mysql.com/doc/refman/5.7/en/server-system-
variab...](https://dev.mysql.com/doc/refman/5.7/en/server-system-
variables.html#sysvar_secure_file_priv)

~~~
JdeBP
A lot of people it seems are missing the fact that using SELECT ... INTO is
merely _one of three ways_ in which one can arrange to load the malicious
shared library. The other two do not involve OUTFILE/DUMPFILE, and
secure_file_priv does not apply to them.

------
jschneiderhan
While reading this, I couldn't help but wonder what SaaS vendors like AWS
(RDS) do to protect themselves from inevitable RCE that provides a shell to an
attacker. Sooner or later someone is going to get a shell. Do they use
virtualization in a way where rooting a machine doesn't give much of a
foothold into the network?

~~~
scardine
Probably RDS is just a layer over EC2, but I'm not holding my breath waiting
Amazon disclose much information about their setup (I wouldn't).

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).

------
msimpson
If Debian is running mysqld_safe as root then that--alone--is a problem. As
for the rest, they are just configuration mishaps being used with malicious
intent. One could just as easily misconfigure similar services rendering
similar results.

~~~
JdeBP
It's the running it that is the problem, not the running it as root.
mysqld_safe is a Poor Man's Daemon Supervisor, written badly in shell script,
as they always are. It demands running as root, because it has a configuration
parameter of the user that the server program attempts to switch to and that
it chown's various files to.

(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.

* [http://jdebp.eu./Softwares/nosh/mariadb-and-mysql.html](http://jdebp.eu./Softwares/nosh/mariadb-and-mysql.html)

~~~
msimpson
You're right, running mysqld_safe is the problem. However, after a quick bit
of further research, even Debian isn't running mysqld_safe anymore as they now
default to systemd in version 8. So this isn't even a problem in that
distribution unless you make it one.

~~~
JdeBP
Your research was too quick. (-:

Debian 8 packages up mysql 5.5 with only a van Smoorenburg rc script, no
systemd units.

* [https://packages.debian.org/en/jessie/arm64/mysql-server-5.5...](https://packages.debian.org/en/jessie/arm64/mysql-server-5.5/filelist)

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.

* [https://packages.debian.org/en/jessie-backports/arm64/mysql-...](https://packages.debian.org/en/jessie-backports/arm64/mysql-server-5.6/filelist)

* [https://anonscm.debian.org/cgit/pkg-mysql/mysql-5.6.git/tree...](https://anonscm.debian.org/cgit/pkg-mysql/mysql-5.6.git/tree/debian/mysql-server-5.6.mysql.service?id=fcd2771abdb7cc4809f6dfce6d900dbf612e5113)

Apparently, Red Hat Enterprise Linux 7 has no systemd unit files for mysql
5.6, either, and still uses mysqld_safe.

* [http://rpm.pbone.net/index.php3/stat/6/idpl/34647467/dir/red...](http://rpm.pbone.net/index.php3/stat/6/idpl/34647467/dir/redhat_el_7/com/MySQL-server-5.6.33-1.el7.x86_64.rpm)

~~~
msimpson
You're right, again, even though you linked arm64 file lists instead of amd64.
The 5.6 backport does have that unit file, but the badly written one from
Oracle. I guess you shouldn't use Debian (-:

------
segmondy
Reading that CVE is very nostalgic, looks like a 90's era exploit.

------
amq
Does it mean that we could finally get a shell to RDS? Would be interesting to
tinker around.

~~~
evanelias
No, RDS does not give users the SUPER or FILE privileges, which are required
for this exploit.

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.

~~~
ygjb-dupe
So yeah, that means roughly 80% percent of the sites on the internet will be
affected, but not the 20% that employ competent, well staffed infosec teams.
Good to know :)

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...

~~~
evanelias
You don't need a large specialized infosec team to know the following:

* 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.)

------
pixl97
Does this affect any versions older than 5.5?

~~~
luastoned
It clearly affects all versions <= 5.5.52, <= 5.6.33, <= 5.7.15

------
qwertyuiop924
...Is _anyone_ surprised?

Like, at all?

