MySQL : un chercheur dévoile deux failles 0-day « critiques »

L'Oracle n'a rien vu venir

MySQL : un chercheur dévoile deux failles 0-day « critiques »

MySQL : un chercheur dévoile deux failles 0-day « critiques »

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.

Commentaires (45)


Oracle, ô désespoir… encore <img data-src=" />


Oracle bad guys, mais il leur a quand même pas laissé énormément de temps, en pleine période de vacances, avant de publier amha.



Sauf à vouloir faire un coup d’éclat, Il aurait pu attendre un peu plus, sachant qu’il y a une release de mysql prévue mi-octobre, non ?


Ouai enfin si la release à la même faille…


Oracle n’est pas non plus la meilleur société en terme de sécurisation (Java, MySQL)…


Oracle sort ses correctifs via des CPU (critical patch update) tous les 3 mois. Le dernier date de juillet, il fallait peut être attendre le prochain avant de tout publier.


Ou peut-être bien que si. Le fait qu’on en entende souvent parler signifie qu’ils sont actifs et que les failles sont corrigées. Dans le monde des failles, pas de nouvelles signifie mauvaises nouvelles.


Elle était un peu facile celle là… <img data-src=" />

Par contre Le sous-titre de la new est pas mal je trouve.


Eu faut mieux lire le poc … il faut que la configuration mysql ( /etc/mysql/my.cnf ) soit avec les droit en ecriture pour mysql ( afin d’ecraser la config en injection sql et de load des param verollé ).

&nbsp;

99 % des install mysql ont la configuration par defaut /etc/mysql/my.cnf qui appartient&nbsp; a root et mysql ne PEUT PAS ecrire dedans, ce qui rend inexploitable la faille.


Attendre si la correction est compliquée, ok, mais attendre alors que les forkeux ont déjà corrigé ?








gavroche69 a écrit :



Elle était un peu facile celle là… <img data-src=" />

Par contre Le sous-titre de la new est pas mal je trouve.





j’allais faire une blague sur les handicapées mais il parait qu’on a pas le droit <img data-src=" />



Ils sont actif, je ne dis pas l’inverse, mais ils ont plus de faille que pas mal de logiciel (flash les bats :p )

Après plus il y a de monde, plus il y a de faille car elles sont plus découverte, je le conçois… ^^








Dryusdan a écrit :



Ouai enfin si la release à la même faille…











levhieu a écrit :



Attendre si la correction est compliquée, ok, mais attendre alors que les forkeux ont déjà corrigé ?







Une grosse boite qui vend aux pros a des calendriers de release pour que tout soit bien cadré et garantir la qualité de tout ce qui sort. On est pas en mode ‘mercenaire’.







boglob a écrit :



Oracle sort ses correctifs via des CPU (critical patch update) tous les 3 mois. Le dernier date de juillet, il fallait peut être attendre le prochain avant de tout publier.







Ben voilà.



La rançon du succès.








brazomyna a écrit :



Attendre si la correction est compliquée, ok, mais attendre alors que les forkeux ont déjà corrigé ?



Une grosse boite qui vend aux pros a des calendriers de release pour que tout soit bien cadré et garantur la qualité de tout ce qui sort. On est pas en mode ‘mercenaire’.





Ca la fout mal, c’est vrai.









brazomyna a écrit :



Une grosse boite qui vend aux pros a des calendriers de release pour que tout soit bien cadré et garantir la qualité de tout ce qui sort. On est pas en mode ‘mercenaire’.





Alors je vais être plus précis.



Les mercenaires du fork viennent de sortir un patch. Il suffit de regarder les commentaires associés pour au moins avoir une idée de ce qu’il corrige. Et ensuite de faire un essai avec la version d’Oracle…



Donc la sortie des patches sur les forks vaut publication, et demande effectivement une réaction rapide.

&nbsp;









levhieu a écrit :



Donc la sortie des patches sur les forks vaut publication, et demande effectivement une réaction rapide.

&nbsp;





&nbsp;C’pas faux non plus. <img data-src=" />

&nbsp;

&nbsp;



En effet il faut lire mieux le poc, mais aussi complètement ;) Notamment le paragraphe qui commence par :







  1. Create new configuration files within a MySQL data directory (writableby MySQL by default) on _default_ MySQL installs without the need to rely onimproper config permisions.








    Full PoC will be released at a later date, and will show how attackers could# exploit the vulnerability on default installations of MySQL on systems with no# writable my.cnf config files available.









WereWindle a écrit :



j’allais faire une blague sur les handicapées mais il parait qu’on a pas le droit <img data-src=" />





J’espère que ça n’amènerait pas des mois en prisons ?&nbsp;<img data-src=" /> (je ne sais pas mais je me rends compte que les gens deviennent de plus en plus susceptibles)&nbsp;









levhieu a écrit :



Alors je vais être plus précis.



Les mercenaires du fork viennent de sortir un patch. Il suffit de regarder les commentaires associés pour au moins avoir une idée de ce qu’il corrige. Et ensuite de faire un essai avec la version d’Oracle…



Donc la sortie des patches sur les forks vaut publication, et demande effectivement une réaction rapide.





+10









neves a écrit :



En effet il faut lire mieux le poc, mais aussi complètement ;) Notamment le paragraphe qui commence par :





Je reste circonspect sur comment tu reload une config qui n’est pas celle du path, creer un fichier dans le _data_ why not mais forcer un reload de se fichier de config sans avoir un acces specifique , c’est trop gros.



Je demande vraiment a voir le poc



Quand on racle les fonds de tiroirs aussi… <img data-src=" />



Correctif maria-db non dispo sous Debian (sauf sous sid) :/


Si j’ai bien compris, l’exploit ne recharge pas la configuration de lui-même, il attend que ça soit fait par un admin (ou une tache planifiée). L’exploit ne fait que modifier la configuration.


+1



Je porte pas Oracle dans mon cœur mais 1 mois c’est court. Ou bien Oracle ne lui pas accusé réception de sa remontée de faille ou bien la faille est extrêmement simple à mettre en œuvre et déjà exploité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.



ok, qui utilise encore mysql d’oracle de toute façon?

MariaDB n’est pas le remplaçant par défaut sur les distrib linux?








Minikea a écrit :



ok, qui utilise encore mysql d’oracle de toute façon?

MariaDB n’est pas le remplaçant par défaut sur les distrib linux?





Les entreprises. S’ils peuvent éviter les soucis d’une migration incertaine de mysql vers mariadb, ils le font.



La faille a été patchée par Oracle la semaine dernière (5.5.525.6.335.7.15), l’article est totalement faux sur ce point.



&nbsphttp://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-33.html

&nbsp;

Privilege escalation was possible by exploiting the way&nbsp;REPAIR TABLE&nbsp;used temporary files. (Bug #24388746)&nbsp;For&nbsp;mysqld_safe, the argument to&nbsp;–malloc-lib&nbsp;now must be one of the directories&nbsp;/usr/lib,&nbsp;/usr/lib64,&nbsp;/usr/lib/i386-linux-gnu, or&nbsp;/usr/lib/x86_64-linux-gnu. In addition, the&nbsp;–mysqld&nbsp;and&nbsp;–mysqld-version&nbsp;options can be used only on the command line and not in an option file. (Bug #24464380)&nbsp;It was possible to write log files ending with&nbsp;.ini&nbsp;or&nbsp;.cnf&nbsp;that later could be parsed as option files. The general query log and slow query log can no longer be written to a file ending with&nbsp;.ini&nbsp;or&nbsp;.cnf. (Bug #24388753)&nbsp;


Moi…. :-)


L’ensemble des entreprises qui en avaient et qui n’ont pas fait de migration dans les deux derniers mois.

Avant que MariaDB devienne leader, il se passera au moins quelques années.


Un mois et demi c’est LONG dans ce domaine. Et les forks de MySQL ont déjà sorti leurs patchs, donc des gens mal intentionnés vont analyser ces patchs (ce qui se fait vu que tout le monde ne met pas à jour, connaitre les failles corrigées est toujours utile pour un black hat) et déterminer comment fonctionne la faille. Donc autant prévenir les utilisateurs, qu’ils puissent prendre des mesures pour réduire le risque.


pourquoi incertaine? mysql, c’est pas non plus super compliqué… et du SQL, si c’est bien implémenté, ça roule tout seul à migrer, surtout entre deux SGBD complètement compatibles entre eux (même base)


Deux de mes projets actuels.&nbsp;

Dans un des deux c’est historique et ce n’est pas remis en cause actuellement (SI d’une boite du CAC40), dans l’autre l’architecture du projet a été décidé il y a 6 mois, donc c’est clairement un choix (projet sur appel d’offre de l’état).



Donc oui il y a encore du monde.&nbsp;<img data-src=" />


En dev ça se fait “facilement”, mais avant le passage en prod il peut se passer plusieurs années, avec des coûts au niveau de l’exploitation pour toutes les opérations à faire sur chaque serveur. Au niveau du support il faut une monté en compétence sur mariaDB, voir refaire des contrats si ce support est externalisé. Il faut également mettre à jour l’ensemble des dossiers d’installation et d’exploitation des applications qui utilisaient mysql.&nbsp;



Quand je vois la galère que c’est pour organiser l’installation d’un correctif et d’un reboot des machines en prod (pour heartbleed si je me souviens bien), changer l’ensemble des bases de données d’un SI c’est forcément le bordel, même lorsque c’est juste passer sur un fork.


SI je ne me trompe pas le chercheur a clairement dévoilé la faille car percona et mariadb on fait le fix donc un petit diff permet de retrouver sans grand mal la faille sur oracle.


bon apparement c’est uniquement pour les serveur mysql qui accepte des connexion publique ( pas de filtrage ip sur le tcp ), donc ne sont pas concerné les sites “normaux”, juste les serveurs mutualisé ou autre qui expose le tcp.


Merci pour la remontée, la mention de ce correctif a été ajoutée. <img data-src=" />&nbsp;Cependant, il n’est pas officiellement lié aux failles/CVE en question et rien ne dit pour le moment qu’il couvre l’ensemble des voies d’exploitation.


Effectivement, la communication c’est pas le fort d’Oracle….


Le point fort d’Oracle ce sont le service juridique et le service commercial ??



(désolé c’était tentant).


Tu as enfin le droit à ta photo ! <img data-src=" />


Perso de ma petite expérience, c’est plus Postgres qui a le vent en poupe que MySQL (ou autre) en tant que SGBD open source dans les entreprises. Des éditeurs de progiciels avec qui j’ai travaillé avaient même commencé à migrer de Oracle vers Postgres.

Avec derrière Oracle DB ou MS SQL en solution pour les gros besoins.



Le principal souci, outre la partie exploitation et support, c’est aussi si la solution BDD exploite du SQL strict ou bien de l’exotique custom comme Oracle DB le fait justement. (passif historique, toussa)


Oui tu as par exemple toutes les procédures stockées et triggers d’oracle qui ne sont pas forcément facilement migrable.&nbsp;



Sinon pour Postgres, j’ai effectivement eu beaucoup de contacts qui m’en ont parlé (en bien), mais je n’ai jamais eu l’occasion de travailler dessus donc je ne pourrais pas dire ses avantages.&nbsp;


Comment peux tu avoir les droits root alors que mysql n’est pas lancé en root… L’élévation de privilège ne pourrait être faite que via une faille dans le kernel linux (ce qui n’est pas le sujet).

Bref lancer mysqld en root, il ne faut pas être bien malin… En tout cas le service de Arch Linux ne lance pas mariaDB en root…


Sont partie les devs MySQL ?? Prochaine étape : filer MySQL à la fondation Apache


MySQL : la NSA exploite deux failles 0-day&nbsp;« critiques »



<img data-src=" />








Dryusdan a écrit :



Ils sont actif, je ne dis pas l’inverse, mais ils ont plus de faille que pas mal de logiciel (flash les bats :p ) android les bat de loin

Après plus il y a de monde, plus il y a de faille car elles sont plus découverte, je le conçois… ^^





<img data-src=" />

flash est mis à jour lui, ce n’est pas le cas d’android, en pratique.









Dryusdan a écrit :



Après plus il y a de monde, plus il y a de faille car elles sont plus découverte, je le conçois… ^^





La DARPA voudrait que cela soit entièrement gérable par l’intelligence artificielle. Hop hackers au chômage. ^^ Ou pas <img data-src=" />



Fermer