Similar results to the --sandbox option can be achieved with --binary-mode:

$ cat /tmp/test.sql

system ls /;

$ mysql < /tmp/test.sql

bin  boot	dev  etc  home	lib  lib64  man  media	mnt  opt  proc	root  run  sbin  scripts  setup.sh  srv  sys  tmp  usr	var

$ mysql --binary-mode < /tmp/test.sql

ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'system ls /' at line 1

This is actually how this issue was discovered - by using --binary-mode to disable client side commands. Are there any undesired side-effects when --binary-mode is used to import a DB dump that prompted creating --sandbox feature?

Decision to always include `/*!999999- enable the sandbox mode */` line when creating a logical dump seems to bring more harm then benefit.

If logical dump was created and being restored without possibility to be tampered with (for example admin creates dump and restores all by himself) - then there is no point in adding the sandbox command. This is because mariadb-dump will never produce a dump which has some client side commands.

If logical dump can be tampered with (for example dump was given to someone we can not trust and later retrieved) - then there is also no point in adding the sandbox commands. This is because evil actor will be able to remove the sandbox enable command or add other malicious commands in front of the sandbox enable command.

The only thing MDEV-21778 changes is that now mariadb-dump always creates dumps which require client side command support because sandbox mode - is a client side command.

it's not MDEV-21778. MDEV-21778 was about adding a long requested sandbox mode to allow using mariadb client with sudo or as login shell.

It was MDEV-33727 that introduced /*!999999\- enable the sandbox mode */, and this was to close CVE-2024-21096. A case with a malicious server sending \-commands to mariadb-dump in place of the valid data. This way \-commands will appear in the non-tampered dump and will be executed when the dump is replayed.

An alternative solution would've been to validate everything that's coming from the server. Which would add a lot of complexity and, most importantly, a noticeable slowdown to mariadb-dump. Considering how extremely unlikely this attack is, slowing down mariadb-dump for every user on every dump seemed like an overkill. MDEV-33727 is as safe, and has no effect on performance whatsoever.

--binary-mode was a good workaround too. Now we'll have to fix it to recognize the \- command.

Thanks for clarification and sorry for mixing up the issues.

So the root cause of CVE-2024-21096 is that mariadb-dump could actually accidentally produce client side commands (by dumping handcrafted DB schema+data) on vanilla mariadb server? Or does it require modified server to send malformed packets to mariadb-dump to trick it into producing dumps with client-side commands?

It requires a modified server or man-in-the-middle. That's why it's "extremely unlikely".

As a general fwiw/fyi note, --binary-mode is very important for testing purposes (I was instrumental for it's original implementation in the client) - and while it does not look like it's being considered - keeping it's current operation would be preferred.

Indeed --binary-mode block most but not all client side commands does not seem right.

I think this could be easily resolved if mariadb-dump would have an optional CLI flag to NOT add the
- command at the beginning of dump output. Any users who trust the server or plan to use --binary-mode when restoring the backup would toggle this flag and continue having old mariadb-dump behaviour - not adding any client side commands.

I see. Ok, "keeping it's current operation would be preferred" in my last comment can be "keeping it's current operation, plus any additional blocking of '\-', would be fine". In principle though, isn't it supposed to work already? From the code (client/mysql.cc):

  {"binary-mode", 0,

   "Binary mode allows certain character sequences to be processed as data "

   "that would otherwise be treated with a special meaning by the parser. "

   "Specifically, this switch turns off parsing of all client commands except "

   "\\C and DELIMITER in non-interactive mode (i.e., when binary mode is "

   "combined with either 1) piped input, 2) the --batch mysql option, or 3) "

   "the 'source' command). Also, in binary mode, occurrences of '\\r\\n' and "

   "ASCII '\\0' are preserved within strings, whereas by default, '\\r\\n' is "

   "translated to '\\n' and '\\0' is disallowed in user input.",

   &opt_binary_mode, &opt_binary_mode, 0, GET_BOOL, NO_ARG, 0, 0, 0, 0, 0, 0},

Binary mode already blocks the \- command.

The problem lies with the change of behaviour in mariadb-dump. It now always adds a line:

/*!999999\- enable the sandbox mode */

This means that DB dump created with mariadb-dump can no longer be restored with mariadb -binary-mode < dump.sql without manually wiping out the first line of dump.sql which has the \ command to enable sandbox mode.

Hmm, I was replying to the earlier statement "Indeed --binary-mode block most but not all client side commands does not seem right."

Using --force may be a temporary workaround? It will skip past the error.

/test/MD170524-mariadb-11.5.0-linux-x86_64-dbg$ cat in.sql

/*!999999\- enable the sandbox mode */

SELECT 1;

/test/MD170524-mariadb-11.5.0-linux-x86_64-dbg$ ./bin/mariadb -A -uroot -S./socket.sock --force --binary-mode test < ./in.sql > mysql.out 2>&1

/test/MD170524-mariadb-11.5.0-linux-x86_64-dbg$ cat mysql.out

ERROR at line 1: Unknown command '\-'.

1

1

It is test case:

create table t1 (a int);

--exec $MYSQL_DUMP test t1 > $MYSQLTEST_VARDIR/tmp/test.sql

drop table t1;

--exec $MYSQL --binary-mode test 2>&1 < $MYSQLTEST_VARDIR/tmp/test.sql

show create table t1;

drop table t1;

--remove_file $MYSQLTEST_VARDIR/tmp/test.sql

The patch is OK to push.

Please only update the upper comment:

  /*

    In binary-mode, we disallow all mysql commands except '\C'

    and DELIMITER.

  */

  if (real_binary_mode)

to mention that '-' (sandbox) is now also allowed in binary mode.

Sorry guys, I'm a bit confused on what I need to do to resolve the issue for myself. My server is currently running 10.6.18 which is affected. My local dev-server is running 11.1.2.

My bug occurs when trying to import a dump created on the server (10.6.18) to my local server (11.1.2).

If I upgrade my server to 10.6.19, will the dump files return to compatibility with my local server or will I need to update my local server as well?

you'll need to upgrade your local server, but you don't need to update 10.6.18.

in fact, you only need to update your local client, not even the server, but updating everything might be simpler,

@Sergie

Thanks for the reply!

My local server/client is from MariaDB 11.1.2 - Which I now see is a Short Term Release.

Looking at my upgrade path (again on windows), I can go to 11.2.x, 11.3.x, or 11.4.x

Looking over the notes, it seems like 11.2.x and 11.3.x were kind of like stepping stone releases to get to the current 11.4.x long term release version.

Given that, should I treat an upgrade from 11.1.2 -> 11.4.2 as a "major version upgrade" or given the "rolling" nature of these in-between versions, is it safe to treat this update like a "minor version upgrade" where I can just download the 11.4.2 installer, run it and let it take care of everything?

I appreciate your insight! I'm much more of the "programmer" than the "server admin" so I don't want to cause myself a bunch of grief by doing this wrong! Thanks

Following up -

I just treated it like a major version update....

1. Stopped Service
2. Copied database / config directory as backup
3. Installed 11.4
4. Chose upgrade existing
5. Followed update procedure prompts
6. Profit!

This worked great - no issues!

However I tried running my dump file import command and it failed with the same error!
I did some more digging and then it became clear when I ran `mysql --version` and saw that the client binary that was running was a very old version back from when I had 10.6 installed and never full removed it from my machine!

It turns out, I still had the 10.6/bin directory in my environment path so when I would run the mysql command line tool it was running an outdated client, rather than the version that came with the server I was actively using!

I probably didn't need to update my local server at all, rather just needed to fix my path and get rid of the old installations.... Though I'm not complaining, at least now I'm on an LTS release <3!

Given that, should I treat an upgrade from 11.1.2 -> 11.4.2 as a "major version upgrade" or given the "rolling" nature of these in-between versions, is it safe to treat this update like a "minor version upgrade" where I can just download the 11.4.2 installer, run it and let it take care of everything?

We've changed this recently, so the answer is longer than I'd prefer it to be. 11.1 and 11.2 are Short-Term Release, supported for one year (that's the short term). They aren't rolling and you should basically treat 11.1->11.4 as a major upgrade. Depending on your linux distro the package manager might refuse to do an automatic major upgrade.

11.3 and up (except 11.4) are rolling, indeed. If you decide to roll, the upgrade path is 11.3.2->11.4.2->11.5.2->11.6.2, this is minor upgrade, basically, packages should upgrade automatically.

11.4 is LTS, if you stay on it the upgrade path is 11.4.2->11.4.3->11.4.4... etc, these are patch upgrades, always were automatic.