Unknown command “-“) or 17 years of insecure MySQL client
Preface
We use MariaDB in our work and have never had any problems with its operation before.
There's nothing better on Monday morning than a cup of invigorating coffee The programmer’s cry: “We don’t import the database from production on our LAN!” It's really invigorating. It’s a shame I even thought: were they planting viruses on us? Considering that the environment deployed on the local machine is exactly the same as on the production one… Well, almost the same…
Investigation
The first line of the SQL dump contained a very strange line:
/*!999999\- enable the sandbox mode */
-- MariaDB dump 10.19 Distrib 10.11.8-MariaDB, for Linux (x86_64)
--
-- Host: localhost Database: test.ru
-- ------------------------------------------------------
-- Server version 10.11.8-MariaDBCome on? What is it? What kind of sandbox mode?
I compared the database versions on the server and on the local computer.
On server
mariadb Ver 15.1 Distrib 10.11.8-MariaDB, for Linux (x86_64) using EditLine wrapper
On your local computer:
mariadb Ver 15.1 Distrib 10.11.7-MariaDB, for Linux (x86_64) using EditLine wrapper
Well, they couldn’t have broken the compatibility of export and import in the minor version?
I had to study the Internet in search of an answer and even ask chatGPT. chatGPT came up with some nonsense that I don’t even want to bring up. In general, it’s not surprising – he doesn’t particularly follow the news….
On the Internet, I also couldn’t immediately google anything (or even Google it). I went to read the news on the MariadDB website.
Wow! And here is the news from May 17, 2024, which explains everything – https://mariadb.org/mariadb-dump-file-compatibility-change/
Who is too lazy to read – yes, we have broken compatibility with previous versions of MariaDB as well as with MySQL when importing and exporting SQL dumps and now you will have to delete the first line from the file created by mysqldump (mariadb-dump) if you want it to work as before.
Why, why and how this happened – we’ll figure it out later in the article. And now for now the bare facts and recipes.
The changes affected MariaDB versions 10.5.25, 10.6.18, 10.11.8, 11.0.6, 11.1.5, 11.2.4 and 11.4.2. Starting from these versions, an unfortunate line appears in mysqldump (mariadb-dump), which, when imported in older versions of mariadb (and all versions of mysql), leads to an import error ERROR at line 1: Unknown command "-" . Removing this line allows the import to continue as before.
Recipes for deleting the first line from a mysqldump dump (mariadb-dump)
I’ll immediately give the recipes for deleting the first line, which are given at the link, and add one more comment:
Recipe 1:
You can delete the first line during export So:
mariadb-dump | tail +2Recipe 2:
You can delete the first line during import So:
tail +2 | mariadbRecipe 3 (from comments):
This recipe seemed to me the most universal, because it is suitable for any dumps – those that contain the first line with sandbox mode and those that do not contain it.
sed -i '1{/999999.*sandbox/d}' yourfile.sqlWhat happened?
Where did the fuss even begin? According to the link in the article, everything is described somehow cloudy and indistinct. That is, we are closing some kind of vulnerability and as soon as possible…. I had to dig further.
And then there were two very interesting publications that were not directly related to MariaDB, but were related to MySQL, and, as it turned out, they had common problems.
For those interested – 17 years of insecure MySQL client And Trusting mysqldump and an insecure MySQL client leads to remote code execution. The headlines are of course clickbait, but let's see what's the matter?
Executing code during import or via mysql client
I'll try to be as brief as possible – try running this code (it could easily be part of your imported SQL file):
echo "system touch testfile.txt" | mysql; ls -lDespite the fact that this is like an ordinary SQL file (we are now directly passing the text to mysql as it happens during import), the actions that it performs go far beyond working with the database. It creates a file on your file system. Or maybe perform other actions. Further, everything is limited by the author’s imagination. And rights and restrictions on database users will not help you.
The problem is that the mysql client trusts the imported file too much, which should not be done. It's clear that you carefully separate permissions by user, but not everyone knows that scripts can perform actions outside of MySQL permissions.
It turns out this problem was talked about in the MariaDB community in 2022 Here and even in the MySQL community in 2007 here. That is, the problem has been known since 2007 (hence the clickbait about 17 years).
In addition to the system command, there is also pager – here is an illustration with it:
$ rm -f a_file; mysql; ls -l a_file
> pager touch a_file; select 1; exit;
PAGER set to 'touch a_file'
1 row in set (0.00 sec)
Bye
-rw-r--r-- 1 jgagne jgagne 0 Apr 10 14:40 a_fileWhat to do?
The most radical and correct way was proposed by MariaDB – they introduced a special sandbox mode, which is enabled using the argument --sandbox in the mariadb client or using that very notorious line \- which breaks import on old clients.
Moreover, if everything is clear and obvious with the first argument, do you want additional security? Use an argument! But with the first line that the mariadb-dump command generates and which at the time of publication of the article could not be disabled, I absolutely do not understand – it was possible to do the same thing – add a special argument that either enables or disables this damned line?
By the way, one of the comments says that supposedly the MariaDB team has already come to some kind of solution that will not break compatibility so much. I really couldn't find any information about this.
For the mysql client there is one not very obvious argument that can be used when importing files --binary-mode. It is unknown for what reason – whether this was intended or by accident, but it helps to avoid unwanted behavior when importing files.
If you need to correct the behavior of the mysql client itself, you can use a replacement script that will prohibit the creation of subprocesses. Described in more detail Here.
conclusions
Keep in mind that any imported MySQL script may be unsafe for your system and will open much more than just your system’s database. Use the methods described above, or better yet, switch to new versions of MariaDB to avoid unwanted consequences.
There is no clear response from MySQL yet, although Jean-François Gagné has already submitted a bug report to them and is still waiting for a response.
I hope that everyone who starts to encounter an error in importing MySQL files created using new versions of MariaDB will come to this article on Habré and be able to solve their problems as quickly as possible.
If you have your own thoughts on this matter, welcome to the comments. If there is new information on this matter, I will update the article. I will try to keep everyone updated on the situation with this behavior of mysql and mariadb.
