4 ms·

You're arguing authenticated vs unauthenticated remote code execution. Given MySQL creds and a (fairly common) file write primitive (file upload functionality,

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.

kilburn 10y ago
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...
- _forestfortrees 10y ago
  > 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.
  - Vendan 10y ago
    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".
    - JdeBP 10y ago
      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.
      - Vendan 10y ago
        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...
    - _forestfortrees 10y ago
      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.

kilburn 10y ago

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

_forestfortrees 10y ago
> 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.
- Vendan 10y ago
  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".
  - JdeBP 10y ago
    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.
    - Vendan 10y ago
      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...
  - _forestfortrees 10y ago
    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.