Faille de sécurité : MySQL peut donner les privilèges root à des hackers
Et il n'y a toujours pas de correctif

Le , par Coriolan, Chroniqueur Actualités
MySQL fait partie des systèmes de gestion de bases de données les plus utilisés du monde, que ça soit par le grand public ou par les professionnels. De nombreuses entreprises comme Google, Facebook, Yahoo, YouTube, Adobe, l’utilisent encore pour gagner du temps et faire tourner leurs larges sites web, malgré l’émergence et la montée en puissance de nouvelles solutions, notamment les systèmes de gestion de bases de données NoSQL. MySQL est également plébiscité par les petites entreprises en raison de son prix d'implantation nettement inférieur, qui fait de ce système une solution simple et peu onéreuse à mettre en œuvre pour des applications non critiques.

Le chercheur de sécurité polonais Dawid Golunsku a dévoilé deux vulnérabilités dans MySQL, compromettant la sécurité des serveurs. Le chercheur a détaillé l’une des failles de sécurité et a décrit sa méthode d’exploitation. Oracle n’a toujours pas corrigé les deux vulnérabilités, malgré le fait qu’elles ont été signalées il y a plus de quarante jours.

La première vulnérabilité affecte « tous les serveurs MySQL en configuration par défaut dans toutes les versions de MySQL (5.7, 5.6 et 5.5), dont les dernières versions ». Les variantes liées à MySQL, MariaDB et PerconaDB, n’ont pas été épargnées par cette vulnérabilité, néanmoins, des correctifs leur ont été appliqués.

« 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 », explique le chercheur. La faille CVE-2016-6662 peut être exploitée si un hacker a accès à une connexion authentifiée à une base de données MySQL (à travers une connexion réseau ou une interface web comme phpMyAdmin) ou une injection SQL, même avec les modules SELinux et AppArmor installés. Les attaquants peuvent injecter des réglages malicieux dans les fichiers de configuration MySQL, my.cnf, le but étant d’acquérir l’accès root et d'exécuter un code malicieux additionnel. Cette vulnérabilité fait surface 13 ans après qu’un correctif avait été déployé pour remédier à un problème similaire.

Le chercheur a révélé également l’existence d’une seconde faille, néanmoins il n’est pas entré en détail sur la méthode de son exploitation. « 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 ».

Oracle n’a toujours pas adressé officiellement ces vulnérabilités, même si un correctif de sécurité a été publié il y a quelques jours, afin de limiter le risque. Il parait qu’Oracle a secrètement corrigé quelques bogues révélés par Golunski, en limitant les emplacements valides pour charger une bibliothèque au démarrage du service incriminé et en empêchant la génération des fichiers de configuration .ini ou .cnf par la base de données. Même avec ce correctif (MySQL 5.6.33, 5.7.15 et 5.5.52 ?) , le risque reste élevé, surtout avec la persistance d’une deuxième faille non encore détaillée. Si Golunski a révélé l’existence de la vulnérabilité après un mois et demi, avec un prototype limité, c’est pour mettre en garde les utilisateurs afin qu’ils puissent se protéger.

Il faut rappeler que des forks de MySQL, comme par exemple MariaDB et PerconaDB, ont été aussi notifiés de l’existence de la vulnérabilité, et ont déjà pu déployer des correctifs pour corriger les deux failles.

Source : Legalhackers

Et vous ?

Qu'en pensez-vous ?

Voir aussi :

Forum Sécurité


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de berceker united berceker united - Expert confirmé https://www.developpez.com
le 14/09/2016 à 14:55
Les variantes liées à MySQL, MariaDB et PerconaDB, n’ont pas été épargnées par cette vulnérabilité, néanmoins, des correctifs leur ont été appliqués.

Ce qui me paraît étonnant c'est que les fork ont été patché mais qu'Oracle traîne des claquettes.
Avatar de abriotde abriotde - Membre éclairé https://www.developpez.com
le 14/09/2016 à 15:00
Oracle n'a toujours pas patché sa version de MySQL mais les fork MariaDB et PerconaDB sont corrigé. Le titre de la news est ambigüe on a l'impression que le problème est MySQL. Alors que la source du problème c'est Oracle qui après avoir racheté SUN fait tout pour discréditer les projets open-Sources...
Avatar de Mingolito Mingolito - Membre expérimenté https://www.developpez.com
le 14/09/2016 à 15:00
C'est fait exprès, les commerciaux Oracle appellent tous les compte MySQL pour les faire migrer à Oracle et les faire payer des millions en licences Oracle, c'était le but depuis le début, MysQL ils en ont rien à carrer, pas plus que de Java.

L'important c'est le racket , et de donner des milliards aux actionnaires pour faire monter le prix des options et faire gagner des centaines de millions en options aux dirigeants !


Haha vive le capitalisme triomphant !
Avatar de Pierre Louis Chevalier Pierre Louis Chevalier - Expert éminent https://www.developpez.com
le 14/09/2016 à 15:06
Citation Envoyé par abriotde  Voir le message
Le titre de la news est ambigüe on a l'impression que le problème est MySQL. Alors que la source du problème c'est Oracle qui après avoir racheté SUN fait tout pour discréditer les projets open-Sources...

En quoi c'est ambigue "MySQL" ?
Le nom "MySQL" appartient bien à Oracle, les forks ne s'appellent pas "MySQL", mais mariadb, Percona Server, Drizzle...

Pour le reste tu as raison...
Avatar de Chuck_Norris Chuck_Norris - Membre émérite https://www.developpez.com
le 14/09/2016 à 15:06
Il semblerait que les patchs pour MySQL sont maintenant disponibles, je les ai installés sur mes serveurs via le dépôt debian proposé par Oracle.

C'est expliqué ici : https://www.percona.com/blog/2016/09...cve-2016-6662/

MySQL fixes
You aren’t affected if you use version 5.5.52, 5.6.33 or 5.7.15.

The following Percona Server versions have this fix:

5.5.51-38.1
5.6.32-78.0
5.7.14-7

MariaDB has fixed the issue in 5.5.51, 10.1.17 and 10.0.27

Avatar de Pierre Louis Chevalier Pierre Louis Chevalier - Expert éminent https://www.developpez.com
le 14/09/2016 à 15:15
Le correctif est il complet ou partiel ?

Il parait qu’Oracle a secrètement corrigé quelques bogues révélés par Golunski, en limitant les emplacements valides pour charger une bibliothèque au démarrage du service incriminé et en empêchant la génération des fichiers de configuration .ini ou .cnf par la base de données. Même avec ce correctif (MySQL 5.6.33, 5.7.15 et 5.5.52 ?) , le risque reste élevé, surtout avec la persistance d’une deuxième faille non encore détaillée. Si Golunski a révélé l’existence de la vulnérabilité après un mois et demi, avec un prototype limité, c’est pour mettre en garde les utilisateurs afin qu’ils puissent se protéger.

Avatar de berceker united berceker united - Expert confirmé https://www.developpez.com
le 14/09/2016 à 16:16
Et c'est là que je comprend pas. Pourquoi tenté de faire passer discrètement là ou les autres ont fait quelque chose de concret et publiquement.
Je suis d'accord avec @Mingolito, Oracle ne cherche pas à faire évoluer Mysql ça va faire 11 ans que la version 5 existe. Par contre, je doute qu'Oracle cherche à faire les utilisateurs de Mysql à Oracle. Si j'ai bien lu Oracle SQL n'est pas un serveur de base de données mais un IDE pour Oracle. Il y a quasiment aucune présence d'Oracle chez les hébergeurs, les ressources ne sont pas là ou du moins pas aussi nombreux que Mysql.
Celui qui peut tirer son épingle dans cette affaire c'est PosgtGresql. Dommage qu'ils soit si difficile de trouver un hébergeur ayant pignons sur le web pouvant le proposer.
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 14/09/2016 à 16:31
Citation Envoyé par Mingolito  Voir le message
C'est fait exprès, les commerciaux Oracle appellent tous les compte MySQL pour les faire migrer à Oracle SQL et les faires payer des millions en licences Oracle, c'était le but depuis le début, MySQL ils en ont rien à carrer, pas plus que de Java.

Autant je ne suis pas fan d'Oracle et de sa gestion de l'open source, autant je ne crois pas une seconde qu'ils espèrent qu'un sabordage de MySQL profite a sa base de donnée historique. Ceux qui abandonnent MySQL à cause de sa mauvaise qualité on peu de chance de se laisser attirer par un produit de la même société. De plus il faut voir que les produits sont assez différents, en matière de capacité, simplicité, prix, ...

Ceux qui abandonnent MySQL vont plutôt regarder les solutions de niveau équivalent comme MariaDB (avec lequel la transition sera très simple, vu que c'est un fork) ou PostgreSQL.
Avatar de ovh ovh - Rédacteur https://www.developpez.com
le 15/09/2016 à 14:20
Citation Envoyé par Coriolan  Voir le message
De nombreuses entreprises comme Google, Facebook, Yahoo, YouTube, Adobe, l’utilisent encore pour gagner du temps et faire tourner leurs larges sites web, malgré l’émergence et la montée en puissance de nouvelles solutions, notamment les systèmes de gestion de bases de données NoSQL.

Il serait temps d'arrêter avec cette fausse idée que le nosql est là pour remplacer les bases de données relationnelles, c'est totalement faux !
A tous ceux qui croient cela, je les invite à lire cet excellent article :
http://www.sarahmei.com/blog/2013/11...r-use-mongodb/

Le nosql répond à des usages différents et n'est pas adapté pour stocker des données qui sont relationnelles par nature (et la majorité des données des applications, web ou autres, sont bel et bien relationnelles). Le nosql est plutôt fait pour stocker des données "brutes" en masse, telles que des logs.
Avatar de gerard093 gerard093 - Membre à l'essai https://www.developpez.com
le 23/09/2016 à 12:26
Offres d'emploi IT
Architecte sécurité des systèmes d'information embarqués H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY
Data scientist senior H/F
Safran - Ile de France - Magny-les-Hameaux (Saclay)
Responsable protection des données H/F
Safran - Ile de France - Magny-les-Hameaux (78114)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil