From https://dev.mysql.com/doc/refman/8.0/en/load-data-local.html: There are two potential security issues with the LOCAL version of LOAD DATA: The transfer of the file from the client host to the server host is initiated by the MySQL server. In theory, a patched server could be built that would tell the client program to transfer a file of the server's choosing rather than the file named by the client in the LOAD DATA statement. Such a server could access any file on the client host to which the client user has read access. (A patched server could in fact reply with a file-transfer request to any statement, not just LOAD DATA LOCAL, so a more fundamental issue is that clients should not connect to untrusted servers.) Essentially, the server has full access to the client machine when compiled with -DENABLED_LOCAL_INFILE=1, and as a result it's not safe to connect to a server that you don't completely trust. All of the MariaDB ebuilds currently set -DENABLED_LOCAL_INFILE=1, but hopefully it doesn't break anything to disable it. From that same page: "By default, the client library in MySQL binary distributions is compiled with ENABLED_LOCAL_INFILE disabled."
(In reply to Michael Orlitzky from comment #0) > All of the MariaDB ebuilds currently set -DENABLED_LOCAL_INFILE=1, but > hopefully it doesn't break anything to disable it. From that same page: "By > default, the client library in MySQL binary distributions is compiled with > ENABLED_LOCAL_INFILE disabled." Important fact: All previous versions of MySQL (before 8.0) had this option *enabled* by default in MySQL binary distributions. We also have this enabled for dev-db/mysql as well. Careful consideration needs to be taken on what, if anything, is to be done.
(In reply to Brian Evans from comment #1) > > Important fact: All previous versions of MySQL (before 8.0) had this option > *enabled* by default in MySQL binary distributions. Ugh, I didn't realize that. > Careful consideration needs to be taken on what, if anything, is to be done. While the feature looks useful on the surface, I think this design flaw dooms every scenario in which it could be used. I think this is pretty common: we have a few customers who host their websites on cheap shared hosting rather than directly with us. If I need to load a Wordpress backup or something like that, I have to connect to an untrusted MySQL server. As soon as I connect, the server can tell my client to send it my private gentoo SSH keys that I use to authenticate with dev.gentoo.org. And with ENABLED_LOCAL_INFILE=1, my client will happily (and silently) send them, with no interaction from me whatsoever. Given that risk, the only MySQL servers I can safely connect to are on (physical) servers where I'm root and have built MySQL myself. And in particular, that's a situation where I definitely don't need to use the local file feature. Looking at it from the other way around: the only time I need to upload a file using my MySQL client is when I don't have SSH access to the server, which means that it's untrusted and I can't safely connect to it. This isn't a new vulnerability -- I just happened to learn of it yesterday. It's one of those things that's so outrageously stupid that no one would even think to try it. Exploits have been in the wild for years, for example: https://github.com/allyshka/Rogue-MySql-Server
There is a recent commit [1] related to this subject. Would it be acceptable to change our default to AUTO as this patch propagates? AUTO tells the client a LOAD statement must precede any attempt at a file transfer rather than shutting it off completely. This capability is only good for a single query response. [1] https://github.com/MariaDB/server/commit/2175bfce3e
(In reply to Brian Evans from comment #3) > There is a recent commit [1] related to this subject. > > Would it be acceptable to change our default to AUTO as this patch > propagates? > AUTO tells the client a LOAD statement must precede any attempt at a file > transfer rather than shutting it off completely. This capability is only > good for a single query response. > > [1] https://github.com/MariaDB/server/commit/2175bfce3e I asked about this in a comment on that commit. While it's a no-brainer for people who need to load data from local files, it still leaves a pretty big hole. If you ever actually issue a "load data local..." command, the server can take any file it wants off your local system, and not just the one you specified. Could the build flag be turned into a USE flag? The people who need it could set e.g. USE=local-infile (with a warning in metadata.xml), but it would then be secure by default.
This effects more than just mariadb: dev-db/mariadb/mariadb-10.4.25.ebuild: -DENABLED_LOCAL_INFILE=1 dev-db/mariadb/mariadb-10.3.35.ebuild: -DENABLED_LOCAL_INFILE=1 dev-db/mariadb/mariadb-10.2.44.ebuild: -DENABLED_LOCAL_INFILE=1 dev-db/mariadb/mariadb-10.5.16.ebuild: -DENABLED_LOCAL_INFILE=1 dev-db/mariadb/mariadb-10.6.8-r1.ebuild: -DENABLED_LOCAL_INFILE=1 dev-db/percona-server/percona-server-8.0.25.15-r1.ebuild: -DENABLED_LOCAL_INFILE=1 dev-db/percona-server/percona-server-8.0.26.16-r1.ebuild: -DENABLED_LOCAL_INFILE=1 dev-db/mysql/mysql-5.7.36-r1.ebuild: -DENABLED_LOCAL_INFILE=1 dev-db/mysql/mysql-8.0.27.ebuild: -DENABLED_LOCAL_INFILE=1 dev-db/mysql-connector-c/mysql-connector-c-8.0.27-r1.ebuild: -DENABLED_LOCAL_INFILE=ON dev-db/mysql-connector-c/mysql-connector-c-8.0.27.ebuild: -DENABLED_LOCAL_INFILE=ON mjo's reference 404's for me now, but here's an archived version: https://web.archive.org/web/20210122133706/https://dev.mysql.com/doc/refman/8.0/en/load-data-local-security.html
Upstream defaults to off: https://github.com/mysql/mysql-server/blob/8.0/CMakeLists.txt#L1458 So why did we ever turn it on? In dev-db/mysql, it looks like it was done in: commit c3c4fce5e5171d4ec5ac6e6ec4e2ff84580ab107 Author: Brian Evans <grknight@gentoo.org> Date: Thu Jul 27 18:55:01 2017 -0400 dev-db/mariadb: New revision which removes the mysql-multilib-r1 eclass Package-Manager: Portage-2.3.6, Repoman-2.3.3
