Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Idelways

22PARTAGES

11  1 
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 : Sélectionner tout
$ 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é ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de gb_68
Membre confirmé https://www.developpez.com
Le 15/06/2012 à 0:15
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 : Sélectionner tout
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 : Sélectionner tout
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 : Sélectionner tout
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.
13  0 
Avatar de MiaowZedong
Membre extrêmement actif https://www.developpez.com
Le 14/06/2012 à 13:09
.....

Comme quoi, à négliger les bases pour privilégier le haut niveau, on fait des grosses conneries.
11  1 
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 14/06/2012 à 17:00
Citation Envoyé par Idelways Voir le message

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.
10  0 
Avatar de MiaowZedong
Membre extrêmement actif https://www.developpez.com
Le 14/06/2012 à 15:57
Citation Envoyé par rhludovic Voir le message
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?
7  1 
Avatar de ManusDei
Expert confirmé https://www.developpez.com
Le 14/06/2012 à 15:24
Bon, maintenant la question importante, developpez.net utilise MySQL ?
6  1 
Avatar de camus3
Membre éprouvé https://www.developpez.com
Le 15/06/2012 à 10:03
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 ?
7  2 
Avatar de eti0123456789
Membre du Club https://www.developpez.com
Le 15/06/2012 à 13:23
Citation Envoyé par alex_vino Voir le message
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 !
6  1 
Avatar de berceker united
Expert confirmé https://www.developpez.com
Le 14/06/2012 à 14:40
Citation Envoyé par Bart-Rennes Voir le message
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] .
5  1 
Avatar de camus3
Membre éprouvé https://www.developpez.com
Le 14/06/2012 à 13:21
wow ça fait peur...
3  0 
Avatar de Pill_S
Membre expert https://www.developpez.com
Le 14/06/2012 à 14:10
aie !
2  0