MySQL/MariaDB : alerte à une faille de sécurité "tragiquement comique"

MySQL et MariaDB : alerte à une faille de sécurité "tragiquement comique"
50 % des serveurs seraient touchés


MySQL et son fork MariaDB souffrent d'une grave vulnérabilité à une attaque de force brute, prodigieusement facile à exploiter.

En peu de secondes, un pirate peut contourner l'authentification aux serveurs de base de données pour peu qu'il dispose d'un nom d'utilisateur correct (« root » est en général toujours présent et actif avec un maximum de prévilèges).
Il suffit au pirate de répéter quelques centaines de tentatives de connexion avec un mot de passe erroné et le tour est joué, explique Sergei Golubchi, coordinateur sécurité à MariaDB sur le mailing-list oss-sec.

La faille se situe au niveau d'une librairie C dont dépendent ces SGBD. Il s'agit d'une erreur de casting qui a une chance sur 256 fois de se produire lors de la vérification du résultat de comparaison des mots de passe fournis et attendus (avec la fonction memcmp). De ce fait, entre 300 et 512 tentatives de connexions devraient suffire pour gagner un accès non autorisé à la base.

Code:

---

$ for i in `seq 1 1000`; do mysql -u root --password=bad -h 127.0.0.1 2>/dev/null; done

---

Boucle shell pour tester la vulnérabilité de son serveur

Mais tous les builds ne sont pas vulnérables estime HD Moore, un expert en sécurité reconnu. Les builds officiels ne peuvent en l'occurrence être compromis à partir des versions 5.1.61, 5.2.11, 5.3.5 et 5.5.22.
Ce n'est pas le cas de ceux d'Ubuntu Linux 64-bit (versions 8.04 jusqu'à la 12.04), OpenSuSE 12.1 64-bit MySQL 5.5.23-log, Debian Unstable 64-bit 5.5.23-2, Fedora, et Arch Linux.

Les développeurs d'Ubuntu ont annoncé des mises à jour pour toutes les versions de MySQL depuis Ubuntu 8.04.

Sur les 1.74 million de serveurs identifiés, Moore estime 50 % d'entre eux victimes d'une faille qu'il qualifie de « tragiquement comique ».

En effet, le fix ne requiert la modification que d'une seule ligne de code.
http://idelways.developpez.com/news/...-mysql-fix.png


Sources :
:fleche: post de Sergei Golubchik
:fleche: post de HD Moor
:fleche: bulletin de sécurité
:fleche: Notice de sécurité d'Ubuntu

Et vous ?
:fleche: Vos serveurs sont-ils vulnérables ?
:fleche: Que pensez-vous de cette vulnérabilité ?

.....:calim2:

Comme quoi, à négliger les bases pour privilégier le haut niveau, on fait des grosses conneries.

wow ça fait peur...

aie :aie:!

Je dirai même plus fortement sympathique. ^^'

Bon bein je vais hacker de ce pas... :aie:

Plus sérieusement cette nouvelle fait tache pour MySQL et MariaDB, mais bonne initiative de la part d'Ubuntu.

eh bien ça c'est de l'info avec en prime l'exemple exacte pour réaliser l'attaque :ccool: Comme ça tous les apprentis sorciers vont devenir grands maitre en quelques secondes...

Citation:

---

Envoyé par Bart-Rennes

eh bien ça c'est de l'info avec en prime l'exemple exacte pour réaliser l'attaque :ccool: Comme ça tous les apprentis sorciers vont devenir grands maitre en quelques secondes...

---

Non le but, c'est que le entreprise puissent prendre le problème au sérieux de faire la correction très rapidement. C'est à dire de retirer [Root] .

Ça ne fait vraiment pas sérieux. Comment n'a-t-on pas pu s'en rendre compte avant !

La plupart du temps, il y a une restriction sur l'ip; soit uniquement en localhost (site web), soit l'utilisateur est restreint sur une ip. Quel est votre avis?

Citation:

---

Envoyé par GATEN

Ça ne fait vraiment pas sérieux. Comment n'a-t-on pas pu s'en rendre compte avant !

---

Ceux qui cherchent a pirater une base de données sont en général (juste en général :)) mal intentionnés, et n'ont rien a gagner en donnant leurs petits secrets au monde entier.

Je ne suis pas expert en sécurité, mais le probleme ici est qu'il faille effectuer une boucle, en général on teste une fonction sans faire une boucle de 300 passage consécutifs sur celle-ci.
Le probleme était plus en bas-niveau

Salut.

Perso mon serveur MySql et sur fedora, donc j'ai l'accès qu'en locahost a mon server SQL donc pas de problèmes au niveau de l'attaque car faut déjà entrer sur ma machine.

J'ai quand même testé en local l'attaque pour le fun :mouarf: et ça fonctionne parfaitement, c'est pas très rassurant quand même.

Bon, maintenant la question importante, developpez.net utilise MySQL ? :mrgreen:

C'est marrant,

j'ai vu en cours y'a pas si longtemps que ça qu'on pouvait attaquer memcmp de cette façon ...
Testé en local avec une ubuntu 64 bits, pas eu de soucis (Et comme bien d'autres, j'avais activé l'accès en local exclusif pour la base ^^).

Citation:

---

Envoyé par buse974

Perso mon serveur MySql et sur fedora, donc j'ai l'accé qu'en locahost a mon server SQL donc pas de probléme au niveau de l'attaque car faut déja entrer sur ma machine.

---

Donc, la question est : mon site est-il sécurisé contre les CSRF qui pourrait avoir accès à ma DB. Dans ce cas, l'attaque de la DB a lieu depuis localhost. :aie:

Citation:

---

« tragiquement comique ».

---

Je n'ai jamais vu de faille qualifié ainsi. Cette faille est tellement facile à exploiter. Je me demande bien comment a-t-on fait pour ne pas s'en apercevoir avant?

Quand on pense au nombre de serveurs utilisant MySQL, ça fait froid dans le dos.

Citation:

---

Envoyé par rhludovic

Je n'ai jamais vu de faille qualifié ainsi. Cette faille est tellement facile à exploiter. Je me demande bien comment a-t-on fait pour ne pas s'en apercevoir avant?

Quand on pense au nombre de serveurs utilisant MySQL, ça fait froid dans le dos.

---

Qui te dit que la faille n'a pas été déjà exploitée? ;)

Citation:

---

Envoyé par Idelways

La faille se situe au niveau d'une librairie C dont dépendent ces SGBD. Il s'agit d'une erreur de casting qui a une chance sur 256 fois de se produire lors de la vérification du résultat de comparaison des mots de passe fournis et attendus (avec la fonction memcmp).


:fleche: Que pensez-vous de cette vulnérabilité ?

---

Un peu plus d'explications : la lib teste le mot de passe sur plus de caracteres que ne le supporte mysql, qui tronque donc simplement (cast) avant de faire la comparaison. C'est ballot. Et pour repondre a javaBean, le fait de tronquer une valeur est une connerie du developpeur qui n'a rien a voir avec le langage utilise.

Cette vulnerabilite montre bien que, lorsqu'on ne sait pas ce que l'on fait, il y a des chances pour que ca se passe mal.
La securite est souvent ajoutee en dernier, apres que l'application ait ete developpee, par des gens n'y connaissant pas forcement grand chose. Dans ce cas, le bugfix est dramatiquement simple, mais il y a des cas ou c'est tout le design de l'application qu'il faut revoir, pour la meme faute de conception au demarrage.

C'est pas trop étonnant quand on connaît l'histoire de ce "SGBD".

Sinon c'est humain de faire des erreurs mais la question intéressante c'est de savoir avec qu'elle facilité on peut les détecter, surtout si elles sont critiques.

J'avoue ne pas avoir tout de suite compris ce bug ayant une probabilité de 1/256.
Voici quelques morceaux codes complémentaires :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

/*   Check that scrambled message corresponds to the password; the function [...]   RETURN VALUE   0 password is correct   !0 password is invalid */   my_bool check_scramble(const char *scramble_arg, const char *message, const uint8 *hash_stage2) {

---

Donc la fonction doit renvoyer 0 si le mot de passe est correcte et un nombre quelconque différent de zéro dans le cas contraire.
C'est bien ce que fait memcmp

Code:

---

return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE);

---

Le hic est que le type retourné par memcmp est un int alors que my_bool est défini comme suit (/include/my_global.h) :aie:

Code:

---

typedef char my_bool; /* Small bool */

---

Le cast int -> char revient à faire un modulo 256, soit transformer toutes les valeurs multiples de 256 en 0. Si l'on considère que memcmp va nous renvoyer de manière uniforme toutes les valeurs possibles alors l'on obtient cette roulette russe de 1/256 pour le mot de passe.