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

50 % des serveurs seraient touchés

Le 2012-06-14 12:52:46, par Idelways, Expert éminent sénior

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 bash :

$ 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.

Sources :

post de Sergei Golubchik

post de HD Moor

bulletin de sécurité

Notice de sécurité d'Ubuntu

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

Discussion forum

33 commentaires

gb_68

Membre confirmé

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

Code C :

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 C :

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)

Code C :

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.

le 15/06/2012 à 0:15

MiaowZedong
Membre extrêmement actif

.....

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

le 14/06/2012 à 13:09
gangsoleil
Modérateur

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).

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.

le 14/06/2012 à 17:00
MiaowZedong
Membre extrêmement actif

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?

le 14/06/2012 à 15:57
camus3
Membre éprouvé

En même temps cela prouve l'utilité de l'open source.
Combien de bugs inconnus et failles existent dans les SGBD dont le code est fermé ? de plus le fix est simple suffit de corriger et de recompiler.

Bref on peut tout à faire faire du proprio , mais l’accès aux sources d'un produit permet finalement de pointer facilement des bugs ou des failles de sécurités.

Comment savoir si tel ou tel système proprio n'a pas de backdoor ?

le 15/06/2012 à 10:03
ManusDei
Expert confirmé

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

le 14/06/2012 à 15:24
eti0123456789
Membre du Club

Envoyé par alex_vino

Bah l'avantage de ne pas avoir acces au code sources empeche les hackers de trouver des failles en regardant juste le code source.
Ca leur demande beaucoup plus de travail aux hackers et d'avancer a tatonnement

Celà n'empêche pas non plus les logiciels propriétaires d'être également touchés par des failles simplement exploitables, on a vu par exemple la CVE-2010-4669, où le fait de lancer un grand nombre de RA IPv6 sur un réseau avec un sipmple script fait planter les machines Windows du réseau... Et on pourrait noter que contrairement à la faille de MySQL, celle-ci ne semble toujours pas corrigée !

le 15/06/2012 à 13:23
berceker united
Expert éminent

Envoyé par Bart-Rennes

eh bien ça c'est de l'info avec en prime l'exemple exacte pour réaliser l'attaque 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] .

le 14/06/2012 à 14:40
camus3
Membre éprouvé

wow ça fait peur...

le 14/06/2012 à 13:21
Pill_S
Membre expert

aie !

le 14/06/2012 à 14:10

Poster une réponse