Le chercheur Dawid Golunski signale deux vulnérabilités dans MySQL, qu'Oracle n'a pas encore corrigées officiellement. Elles permettent de compromettre un serveur dans une variété de situations, notamment via une simple injection SQL. MariaDB et PerconaDB, eux, ont déployé des correctifs.
Il y a des records dont on se passerait facilement. Hier, le chercheur polonais Dawid Golunski a révélé deux failles dans MySQL, dont l'une détaillée avec une méthode d'exploitation. La principale, CVE-2016-6662, a été signalée à Oracle il y a plus de 40 jours, sans réaction du géant du logiciel. Jugées critiques, ces deux vulnérabilités peuvent avoir des conséquences très fâcheuses.
Accéder aux privilèges root, via une injection SQL
« Une exploitation réussie [de la vulnérabilité CVE-2016-6662] permettrait à un attaquant d'exécuter du code arbitraire avec les privilèges root, ce qui lui permettrait de compromettre entièrement le serveur » détaille l'expert. Elle peut être exploitée localement ou à distance, autant via une accès avec authentification ou une injection SQL, même avec les modules SELinux et AppArmor installés. Toutes les versions de MySQL « en configuration par défaut » sont touchées (5.7, 5.6 et 5.5). Cette vulnérabilité permettrait d'outrepasser un correctif mis en place il y a 13 ans, destiné à bloquer un problème similaire.
Il a également révélé l'existence d'une seconde vulnérabilité, qu'il n'a pas encore détaillée. « Il est à noter que des attaquants peuvent utiliser l'une des autres failles découvertes par l'auteur de ce bulletin, auquel a été assigné l'identifiant CVE CVE-2016-6663 et est en attente de publication. Cette faille facilite la création d'un fichier /var/lib/mysql/my.cnf au contenu arbitraire, sans besoin du privilège FILE » explique le chercheur. En clair, l'exploitation de la première faille pourrait devenir triviale.
Un correctif qui ne vient pas officiellement chez Oracle
Les failles ont été signalées à Oracle le 29 juillet. Sans retour de l'éditeur après un mois et demi, Dawid Golunski a donc décidé de dévoiler la vulnérabilité, avec un prototype limité. Le but : prévenir les utilisateurs du risque que pose ces failles, vu que l'éditeur n'a pas encore daigné le faire lui-même.
Oracle a tout de même corrigé, il y a quelques jours, une fonction impliquée dans l'exploitation de la vulnérabilité avec MySQL 5.5.52, 5.6.33 et 5.7.15, sans pour autant mentionner directement la faille. Concrètement, elle limite les emplacements valides pour charger une bibliothèque au démarrage du service incriminé. Pour autant, rien ne garantit actuellement qu'elle règle complètement le problème, d'autant que la seconde vulnérabilité n'a pas encore été publiée.
Oracle n'a pas été le seul éditeur prévenu. MariaDB et PerconaDB, qui partagent la base du code de MySQL, ont eux aussi reçu les détails. Au 30 août, les deux éditeurs ont corrigé leurs logiciels pour faire face aux deux vulnérabilités.
Contacté par Threatpost, Oracle n'a pas souhaité commenter la nouvelle. Le correctif officiel devra sûrement attendre le 18 octobre, avec la prochaine fournée de correctifs critiques de MySQL. En attendant, le chercheur recommande de vérifier qu'aucun fichier de configuration n'est « possédé » par l'utilisateur mysql et de créer de faux fichiers my.cnf détenus par l'utilisateur root.
Rappelons que les attaques sur les bases de données peuvent avoir des conséquences graves, comme l'ont bien montré les nombreuses remontées de fuites de données de ces derniers, notamment celle de Dropbox en 2012, qui hante l'entreprise depuis plus de quatre ans. Les problèmes de sécurité de logiciels populaires, comme le système de forum vBulletin, peuvent aussi mener à des fuites sur d'importants sites qui se passent des mises à jour. Encore faut-il que l'éditeur propose un correctif, donc, ce qu'Oracle ne semble pas encore pressé de faire.
