Many of you have probably already heard about the new vulnerability affecting most existing MySQL forks and versions. The bug has been patched in some of the most recent MySQL and Percona Server releases and so, at least in theory, all it takes to apply a fix is to update the MySQL or Percona Server packages to their latest versions. However, it would likely require a database restart and restarts are never particularly convenient, especially when done in a rush. But this time it is actually possible to fix the vulnerability without having to upgrade and restart your MySQL instances immediately.
The attack relies on the ability to load a forged memory allocator library through --malloc-lib option in one of the MySQL start-up scripts. This can only happen if such library is first uploaded to server through the MySQL's SQL interface using a specially-crafted SELECT INTO [DUMPFILE|OUTFILE] command to a directory MySQL has a write permission to. This generally limits the attack vector to paths like /tmp, and /var/lib/mysql or another location you configured as the MySQL data directory.
The available patches are roughly several lines of bash code that essentially filter out any arguments for --malloc-lib that do not start with /usr/lib, /usr/lib64 and other similar prefixes; i.e. places where no shared libraries should normally be stored.
Here is how Oracle handled it:
https://github.com/mysql/mysql-server/commit/f75735e36e6569b9dae3b0605b1d5915a519260e#diff-144aa2f11374843c969d96b7b84247eaR348
The 10 lines following "# Restrict to a the list in $malloc_dirs above".
And here's the Percona version:
https://github.com/percona/percona-server/commit/c14be53e029442f576cced1fb8ff96b58e89f2e0#diff-144aa2f11374843c969d96b7b84247eaR261
The 8 lines following "# Check if the library is in the reduced number of standard system directories".
So what do you need to do? Just edit in these changes into the appropriate location inside mysqld_safe file on your MySQL server. Typically it will be /usr/bin/mysqld_safe. This is all you need to do to protect your server against this particular vulnerability. No package upgrade nor any restart required.
Anyone with database access and both FILE and SELECT privileges may still be able to upload the forged memory allocator library to the server as this can only be stopped with the correct configuration of secure-file-priv, but at least now the MySQL will refuse to load it during restart.
Do you want to help you secure your MySQL server? Contact Us.