7 ms·

MySQL client allows MySQL server to request any local file

137 points by cnst 8y ago

billsmithaustin 8y ago
But only with a modified MySQL server.
- DougBTX 8y ago
  Or rephrased, this is an attack on a vulnerable MySQL client by a malicious MySQL server, rather than a more typical “client attacks server” threat.
  - kijin 8y ago
    It sounds similar to the recently discussed scp vulnerability [1] where a malicious SSH server could drop files onto the client. [1] https://news.ycombinator.com/item?id=18909289 https://news.ycombinator.com/item?id=18909289
  - weknowbetter 8y ago
    "Server attacks client" is pretty common with web browsers. Probably more common than the other way around. Much less common with Database clients of course.
- ryebit 8y ago
  Yeah, i definitely think common workflow rarely involves connecting to untrusted servers. But... If server gets hacked, connecting in to see why your site is down could steal files before you know what happened. Even better if hack isn't visibly causing problems. Though that seems really indirect and unproductive an attack vector. But sounds great for a honeypot. Put up an easy-to-hack WordPress server, and when attacker connects to mysql, start downloading all the PII files you can think of from the client.
  - iancarroll 8y ago
    And of course, this article is about how the Adminer database tool was weaponized with this vulnerability to steal data.
  - zAy0LfpBZLC8mAC 8y ago
    What is it with this concept of "(un)trusted servers" that people throw around here all the time that seems to build on the assumption that the world consists only of entities that are to be distrusted and those that should have full access to and control over all your information and resources? No, just because I don't expect my client to kill me, does not mean that therefore there is no reason to be concerned about a rogue employee of theirs being able to gain access to any other of my clients' servers that I have access to by patching an exploit into their MySQL server. Nor is it reasonable to assume that everyone is on top of their IT security and their infrastructure is only under their own control, and that includes your own organization once it grows beyond one or two people. If that is the kind of mental model you are working with, your IT security probably is shit. Even the slightest external vulnerability anywhere in your systems or the systems of people whose systems you access/(co-)manage is going to grant an attacker total control over your organization if that is how you manage security.
  - ivanhoe 8y ago
    Is there really such thing as a trusted server? Any server could have been hacked, it's not something that's under your control, so it's better to be a bit more paranoid about this.
- deleted 8y ago
  [deleted]
- joelhaasnoot 8y ago
  If you're running a e-commerce site, why would you connect to a rogue MySQL server? I've never had that urge...
- gpvos 8y ago
  Yes, so if your server has been hacked, you now also have been hacked. It's not the most common scenario, but it would be good to protect against it in the interest of defense-in-depth.
lqet 8y ago
Am I understanding this correctly: LOAD DATA LOCAL is used to bulk load datasets (like CSV files) into a MySQL database from the client. Why is the file transfer initiated by the server, and not by the client? Is it because they wanted to cover cases where the server processes / simplifies the query, and after processing, it becomes evident that the file is not needed at all? If so, why isn't there an additional check on the client that the file requested by the server matches a file that was previously used in a LOAD DATA LOCAL query? Is it because there is no query processing / parsing on the client side at all (in case of string SQL queries)?
- beagle3 8y ago
  The client does not parse the SQL prior to sending it to the server. The name of the file may actually be a computation result that depends on data in tables IIRC.
  - adrianmonk 8y ago
    The docs say that it must be a literal: > The file name must be given as a literal string. (From https://dev.mysql.com/doc/refman/8.0/en/load-data.html https://dev.mysql.com/doc/refman/8.0/en/load-data.html ) However, you raise an interesting point about parsing. It is reasonable to want the server to do the parsing. You could, for example, tweak the grammar to add a new feature and do it entirely in an server update without needing to deploy a new client binary to every user. But then that makes it a bit harder to fix bugs like this. There are surely some commands parsed and implemented by the client, though. Like connect, quit, and source for example. So another way to have designed this would be to make a local command to designate a file that the server will be allowed to access. You could define the path name on the client side and pass a symbolic reference to the server. Then the client could parse that command without taking on the burden of parsing SQL, and the client could still own opening files rather than taking orders from the server.
  - frutiger 8y ago
    Sure, but the command could've been: "Load this file: <stream of bytes>", rather than "Load this file: <path to file>" which necessarily requires the server to parse the command.
sehrope 8y ago
The intended usage is that the client tells the server, "I want to load data from a file /path/to/data.txt on my local filesystem" in a SQL command. As part of the protocol for executing the query the server sends a message to the client to request the contents of /path/to/data.txt. Unfortunately client's don't validate the file request and will send any file (ex: /path/to/secrets.txt) even if there was no legit data request in their command. This has been an issue with MySQL client drivers for years. I found and fixed the same issue in MariaDB Connector/J (JDBC driver (wire compatible with MySQL databases) in 2015. It rejects LOCAL DATA requests from the server unless the client app preregistered an InputStream (Java interface for generic stream of bytes) as data for the command being executing. This is one of the many many reasons I love open source database drivers. I was able to find and fix this issue only because I could see the source code. Similar "features" in proprietary databases could go unnoticed for years and even when discovered may not have feature flags to disable them.
- ransom1538 8y ago
  Uh. Ok. "I was able to find and fix this issue only because I could see the source code." This is how all security issues happen. If I was as terrible person, i would create scripts that pray upon people that didnt' patch.
  - nebulous1 8y ago
    People find vulnerabilities in closed source software too, they just don't have the source to patch it.
    - deathanatos 8y ago
      Actually, I think there are cases where people have patched closed source software. Binary patches are possible, just harder to write. (Not trying to say you're wrong: it's definitely easier if one has the source. Only that some humans are both determined and skilled, and some incredible stuff comes from that combination.) IIRC, there was a flaw in Flash patched in this manner; it was using memcpy(), which requires the source and destination regions to not overlap, but, they did. In this case, it's fairly simple: one just needs to call memmove(), which conveniently takes the same args in the same order. (IIRC, there was a lot of consternation getting Adobe to fix that properly, given how obvious the bug was.)
ams6110 8y ago
This is an issue that something like openbsd's pledge can prevent. No reason for the MySQL client to be able to read arbitrary files on the system. https://man.openbsd.org/pledge https://man.openbsd.org/pledge
- shawnz 8y ago
  Pledge could only prevent this by effectively disabling the feature entirely. If you were to implement the necessary logic to determine which "LOCAL DATA" statements were legal and which weren't, it would be trivial from that point to block the illegal ones with or without pledge. Pledge is meant to be used for stopping your software from doing unanticipated things, not anticipated things. In this case they anticipated this behavior and purposely kept it even though it's potentially dangerous. EDIT: Sorry, perhaps you meant that the application which is embedding the MySQL client ought to use pledge. In that case, that does seem like a good defensive usage of pledge which would prevent this kind of attack, notwithstanding the need to fix the issue in the client itself.
- wolf550e 8y ago
  And if you use mysql client to upload files to the mysql server (like csv files) then you could invoke the mysql client with a command line argument saying "I intend to send files from this directory to the server" and pledge would let the process read files from that directory but not others.
- giornogiovanna 8y ago
  This is incredibly off-topic, but can I use pledge as a sandbox by pledging and then execve-ing?
  - throwawaypled 8y ago
    if you pass the `execpromises` parameter, and make sure that the flags DO NOT include the ability to further execve() (the `exec` flag), then yes, but openbsd pledge flags are not implicitly inherited like linux seccomp filters.
deleted 8y ago
[deleted]
lefred 8y ago
by default, LOAD DATA LOCAL INFILE in libmysql is disabled by default to avoid such problem

137 points by cnst 8y ago

billsmithaustin 8y ago

But only with a modified MySQL server.

DougBTX 8y ago
Or rephrased, this is an attack on a vulnerable MySQL client by a malicious MySQL server, rather than a more typical “client attacks server” threat.
- kijin 8y ago
  It sounds similar to the recently discussed scp vulnerability [1] where a malicious SSH server could drop files onto the client. [1] https://news.ycombinator.com/item?id=18909289 https://news.ycombinator.com/item?id=18909289
- weknowbetter 8y ago
  "Server attacks client" is pretty common with web browsers. Probably more common than the other way around. Much less common with Database clients of course.
ryebit 8y ago
Yeah, i definitely think common workflow rarely involves connecting to untrusted servers. But... If server gets hacked, connecting in to see why your site is down could steal files before you know what happened. Even better if hack isn't visibly causing problems. Though that seems really indirect and unproductive an attack vector. But sounds great for a honeypot. Put up an easy-to-hack WordPress server, and when attacker connects to mysql, start downloading all the PII files you can think of from the client.
- iancarroll 8y ago
  And of course, this article is about how the Adminer database tool was weaponized with this vulnerability to steal data.
- zAy0LfpBZLC8mAC 8y ago
  What is it with this concept of "(un)trusted servers" that people throw around here all the time that seems to build on the assumption that the world consists only of entities that are to be distrusted and those that should have full access to and control over all your information and resources? No, just because I don't expect my client to kill me, does not mean that therefore there is no reason to be concerned about a rogue employee of theirs being able to gain access to any other of my clients' servers that I have access to by patching an exploit into their MySQL server. Nor is it reasonable to assume that everyone is on top of their IT security and their infrastructure is only under their own control, and that includes your own organization once it grows beyond one or two people. If that is the kind of mental model you are working with, your IT security probably is shit. Even the slightest external vulnerability anywhere in your systems or the systems of people whose systems you access/(co-)manage is going to grant an attacker total control over your organization if that is how you manage security.
- ivanhoe 8y ago
  Is there really such thing as a trusted server? Any server could have been hacked, it's not something that's under your control, so it's better to be a bit more paranoid about this.
deleted 8y ago
[deleted]
joelhaasnoot 8y ago
If you're running a e-commerce site, why would you connect to a rogue MySQL server? I've never had that urge...
gpvos 8y ago
Yes, so if your server has been hacked, you now also have been hacked. It's not the most common scenario, but it would be good to protect against it in the interest of defense-in-depth.

lqet 8y ago

Am I understanding this correctly: LOAD DATA LOCAL is used to bulk load datasets (like CSV files) into a MySQL database from the client. Why is the file transfer initiated by the server, and not by the client? Is it because they wanted to cover cases where the server processes / simplifies the query, and after processing, it becomes evident that the file is not needed at all? If so, why isn't there an additional check on the client that the file requested by the server matches a file that was previously used in a LOAD DATA LOCAL query? Is it because there is no query processing / parsing on the client side at all (in case of string SQL queries)?

beagle3 8y ago
The client does not parse the SQL prior to sending it to the server. The name of the file may actually be a computation result that depends on data in tables IIRC.
- adrianmonk 8y ago
  The docs say that it must be a literal: > The file name must be given as a literal string. (From https://dev.mysql.com/doc/refman/8.0/en/load-data.html https://dev.mysql.com/doc/refman/8.0/en/load-data.html ) However, you raise an interesting point about parsing. It is reasonable to want the server to do the parsing. You could, for example, tweak the grammar to add a new feature and do it entirely in an server update without needing to deploy a new client binary to every user. But then that makes it a bit harder to fix bugs like this. There are surely some commands parsed and implemented by the client, though. Like connect, quit, and source for example. So another way to have designed this would be to make a local command to designate a file that the server will be allowed to access. You could define the path name on the client side and pass a symbolic reference to the server. Then the client could parse that command without taking on the burden of parsing SQL, and the client could still own opening files rather than taking orders from the server.
- frutiger 8y ago
  Sure, but the command could've been: "Load this file: <stream of bytes>", rather than "Load this file: <path to file>" which necessarily requires the server to parse the command.

sehrope 8y ago

The intended usage is that the client tells the server, "I want to load data from a file /path/to/data.txt on my local filesystem" in a SQL command. As part of the protocol for executing the query the server sends a message to the client to request the contents of /path/to/data.txt. Unfortunately client's don't validate the file request and will send any file (ex: /path/to/secrets.txt) even if there was no legit data request in their command. This has been an issue with MySQL client drivers for years. I found and fixed the same issue in MariaDB Connector/J (JDBC driver (wire compatible with MySQL databases) in 2015. It rejects LOCAL DATA requests from the server unless the client app preregistered an InputStream (Java interface for generic stream of bytes) as data for the command being executing. This is one of the many many reasons I love open source database drivers. I was able to find and fix this issue only because I could see the source code. Similar "features" in proprietary databases could go unnoticed for years and even when discovered may not have feature flags to disable them.

ransom1538 8y ago
Uh. Ok. "I was able to find and fix this issue only because I could see the source code." This is how all security issues happen. If I was as terrible person, i would create scripts that pray upon people that didnt' patch.
- nebulous1 8y ago
  People find vulnerabilities in closed source software too, they just don't have the source to patch it.
  - deathanatos 8y ago
    Actually, I think there are cases where people have patched closed source software. Binary patches are possible, just harder to write. (Not trying to say you're wrong: it's definitely easier if one has the source. Only that some humans are both determined and skilled, and some incredible stuff comes from that combination.) IIRC, there was a flaw in Flash patched in this manner; it was using memcpy(), which requires the source and destination regions to not overlap, but, they did. In this case, it's fairly simple: one just needs to call memmove(), which conveniently takes the same args in the same order. (IIRC, there was a lot of consternation getting Adobe to fix that properly, given how obvious the bug was.)

ams6110 8y ago

This is an issue that something like openbsd's pledge can prevent. No reason for the MySQL client to be able to read arbitrary files on the system. https://man.openbsd.org/pledge https://man.openbsd.org/pledge

shawnz 8y ago
Pledge could only prevent this by effectively disabling the feature entirely. If you were to implement the necessary logic to determine which "LOCAL DATA" statements were legal and which weren't, it would be trivial from that point to block the illegal ones with or without pledge. Pledge is meant to be used for stopping your software from doing unanticipated things, not anticipated things. In this case they anticipated this behavior and purposely kept it even though it's potentially dangerous. EDIT: Sorry, perhaps you meant that the application which is embedding the MySQL client ought to use pledge. In that case, that does seem like a good defensive usage of pledge which would prevent this kind of attack, notwithstanding the need to fix the issue in the client itself.
wolf550e 8y ago
And if you use mysql client to upload files to the mysql server (like csv files) then you could invoke the mysql client with a command line argument saying "I intend to send files from this directory to the server" and pledge would let the process read files from that directory but not others.
giornogiovanna 8y ago
This is incredibly off-topic, but can I use pledge as a sandbox by pledging and then execve-ing?
- throwawaypled 8y ago
  if you pass the `execpromises` parameter, and make sure that the flags DO NOT include the ability to further execve() (the `exec` flag), then yes, but openbsd pledge flags are not implicitly inherited like linux seccomp filters.

deleted 8y ago

[deleted]

lefred 8y ago

by default, LOAD DATA LOCAL INFILE in libmysql is disabled by default to avoid such problem