Cette vulnérabilité a été découverte par le chercheur Dawid Golunski qui la décrit en détail dans un billet. Une preuve de concept (limitée fort heureusement) est également donnée dans ce billet.

La vulnérabilité, si exploitée, permet d'exécuter du code arbitraire à distance avec les privilèges root, via une attaque par injection SQL. Tous les systèmes MySQL 5.5, 5.6, 5.7 dans leur configuration par défaut sont vulnérables.

Le fond du problème est que quand MySQL est lancé classiquement, par /etc/init.d/mysql start, ou service mysql start ou encore systemctl start mysql, le script wrapper mysqld_safe est lancé avec les droits de root, ainsi que chacun peut facilement le vérifier :

ps -ef | grep mysql
root      7638     1  0 Feb17 ?        00:00:00 /bin/sh /usr/bin/mysqld_safe
mysql     8071  7638  5 Feb17 ?        11-18:55:41 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --log-error=/var/log/mysql/error.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306

Or ce script wrapper, aindi que chacun peut le vérifier en lisant son code, peut charger, selon la configuration de /etc/my.cnf (ou autre fichier de configuration de MySQL) une librairie tierce d'allocation mémoire qui aurait été parallèlement uploadée sur le serveur attaqué. Ce faisant il transmet les droits de root à cette librairie tierce. Si cette librairie contient du code malveillant, le serveur sera totalement compromis.

Pour arriver à ce résultat, il suffit de modifier le script de configuration /etc/my.cnf, au moyen d'une injection SQL.

La preuve de concept commence par modifier les permissions du fichier de configuration

chown mysql /etc/my.cnf
chmod 600 /etc/my.cnf" 

Ceci fait, un attaquant qui dispose d'une connexion mysql avec authentification peut injecter du code dans le fichier

mysql> set global general_log_file = '/etc/my.cnf';
mysql> set global general_log = on;
mysql> select '
    '>
    '> ; injected config entry
    '>
    '> [mysqld]
    '> malloc_lib=/tmp/mysql_exploit_lib.so
    '>
    '> [separator]
    '>
    '> ';
1 row in set (0.00 sec)
mysql> set global general_log = off;

Et voilà, au redémarrage du service la libraire mysql_exploit_lib.so pourra sévir.

Comme la preuve de concept le montre, le script de configuration doit avoir des droits correctement positionnés pour limiter les risques d'attaques réussi. Le ficheir ne devrait jamais appartenir à l'utilisateur mysql, bien évidemment, comme le rappelle Dawid Golunski.

Dawid Golunski suggère de leurrer les attaques avec un faux script de configuration, après avoir déplacé le vrai à un emplacement connu seulement de l'administrateur système.

Votre serviteur vous propose d'autres suggestions en complément:

- MySQL doit être configuré pour ne pas permettre d'autres connexions que des connexions locales.

Sachant qu'une attaque peut être tentée depuis un hébergement web après un hack réussi d'un CMS

- ne jamais configurer un CMS avec une connexion de l'utilisateur root de mysql

- ne jamais accorder le droit à l'utilisateur MySQL du CMS d'accorder des permissions

- ne jamais accorder la permission FILE à l'utilisateur MySQL du CMS, afin qu'il ne puisse pas écrire dans un fichier au moyen d'une injection SQL.

- sécurisez très rigoureusement votre phpMyAdmin

Ces 3 précautions s'appliquent d'ailleurs en toutes circonstances. Ce sont des bonnes pratiques

Et bien sûr appliquer les correctifs MySQL dès qu'ils seront disponibles.

C'est là que le bât blesse. Oracle, averti de l'existence de cette vulnérabilité n'a pas l'instant pas communiqué à ce sujet ni annoncé la publication d'un correctif.

MariaDB et PerconaDB, qui dérivent de MySQL ont déjà été patchés par leurs éditeurs.