Hacker News Reader

Comment by feld | Hacker News Reader

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.

View on HN

You're arguing authenticated vs unauthenticated remote code execution.

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.

Giving FILE permissions to MySQL users is "fairly common"? Google it and you'll find that the first page of results are all about people complaining that their piece of software did not grant them such permissions by default. Hence, I totally challenge your assertion.

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

> Giving FILE permissions to MySQL users is "fairly common"?

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.

If you read it, you'd find you need to be either admin on mysql already(and that's a bad thing), or have FILE permission on mysql. It's not about file upload primitive, the exploit is very specifically about the FILE permission on MYSQL allowing the user to add a new trigger as "root".

No, it is not. That's just the third of three ways that it gives in which one can arrange to inject the malicious shared library into the server process. The first and second ways do not involve FILE privilege, nor OUTFILE/DUMPFILE.

The first way involves setting "global general_log_file", which requires SUPER, which is frankly worse having FILE. The second way ALSO involves "global general_log_file", but is incomplete because "One problem will remain however. MySQL will refuse files that do not start with a valid [section] header with the message:" It's stated that there is a workaround, but this still requires SUPER. So yeah, you may not need FILE, you just need SUPER instead, but if you are running a webapp with a mysql user that has SUPER, you are still doing it all wrong...

I certainly did read the writeup. Did you read my comments? I'm not sure what exactly you're disagreeing with.

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.

For shared hosting providers, or any configuration where mysql access control is actually used for anything, this appears fairly critical. Especially for the upcoming PoC that doesn't need /etc/mysql/my.cnf to be writable.

It also means that an SQLi vulnerability suddenly becomes a potential remote root shell.

If a shared hosting provider is giving you FILE permission, you should close your account and leave, cause they don't understand trivial basics of database security.

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

maybe a sql injection ....and escalate from there..

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

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.

I'm sorry I disagree , you're assuming that the "application" is vulnerable to sql injection and others.

Not everyone limits mysql to just localhost.

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.

Reply on news.ycombinator.com