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 !

Une faille dans la conception de MySQL permet à des serveurs malveillants de voler des fichiers à des clients
Elle provient de LOAD DATA LOCAL

Le , par Stéphane le calme

177PARTAGES

15  0 
Un défaut de conception dans l’interaction de transfert de fichier entre un hôte client et un serveur MySQL permet à un attaquant utilisant un serveur MySQL illicite d’avoir accès aux données auxquelles le client connecté a accès en lecture.

Un individu malveillant peut tirer parti de ce problème pour extraire des informations sensibles d'un serveur Web configuré de manière incorrecte qui autorise les connexions à des serveurs non fiables ou à des applications de gestion de base de données.

Les implications pour la sécurité sont connues

Le problème concerne l’instruction LOAD DATA utilisée avec le modificateur LOCAL, qui est considéré comme un risque de sécurité dans la documentation MySQL.

Comme l'expliquent les développeurs, il existe deux problèmes de sécurité potentiels avec la version LOCAL de LOAD DATA:

Le transfert du fichier de l'hôte client vers l'hôte du serveur est lancé par le serveur MySQL. En théorie, on pourrait créer un serveur patché qui indiquerait au programme client de transférer un fichier choisi par le serveur plutôt que le fichier nommé par le client dans l'instruction LOAD DATA. Un tel serveur pourrait accéder à n’importe quel fichier de l’hôte client auquel l’utilisateur client a un accès en lecture. (Un serveur patché pourrait en fait répondre à une requête par une demande de transfert de fichier, pas seulement LOAD DATA LOCAL. Un problème plus fondamental est que les clients ne doivent pas se connecter à des serveurs non fiables.)

Dans un environnement Web où les clients se connectent à partir d'un serveur Web, un utilisateur peut utiliser LOAD DATA LOCAL pour lire tous les fichiers auxquels le processus du serveur Web a un accès en lecture (en supposant qu'un utilisateur puisse exécuter n'importe quelle instruction sur le serveur SQL). Dans cet environnement, le client relatif au serveur MySQL est en fait le serveur Web, et non un programme distant exécuté par les utilisateurs qui se connectent au serveur Web.

Citation Envoyé par administrateurs MySQL
Pour éviter les problèmes liés à LOAD DATA, les clients doivent éviter d'utiliser LOCAL. Pour éviter de se connecter à des serveurs non fiables, les clients peuvent établir une connexion sécurisée et vérifier l'identité du serveur en se connectant à l'aide de l'option --ssl-mode = VERIFY_IDENTITY et du certificat de CA approprié.
Fonctionnement de LOAD DATA LOCAL

Pour permettre aux administrateurs et aux applications de gérer la capacité de chargement de données locales, la configuration LOCAL fonctionne comme suit:

  • Du côté du serveur:
    • La variable système local_infile contrôle la capacité LOCAL côté serveur. Selon le paramètre local_infile, le serveur refuse ou autorise le chargement de données locales par les clients pour lesquels l'option LOCAL est activée côté client. Par défaut, local_infile est désactivé.
    • Pour que le serveur refuse ou autorise explicitement les instructions LOAD DATA LOCAL (quelle que soit la configuration des programmes clients et des bibliothèques au moment de la construction ou de l'exécution), démarrez mysqld avec local_infile désactivé ou activé, respectivement. local_infile peut également être défini à l'exécution.

  • Du côté du client:
    • L'option CMake ENABLED_LOCAL_INFILE contrôle la fonctionnalité LOCAL par défaut compilée pour la bibliothèque client MySQL. Les clients qui ne font pas de dispositions explicites ont donc la capacité LOCAL désactivée ou activée conformément au paramètre ENABLED_LOCAL_INFILE spécifié lors de la compilation de MySQL.
    • Par défaut, la bibliothèque client dans les distributions binaires MySQL est compilée avec ENABLED_LOCAL_INFILE désactivé. Si vous compilez MySQL à partir des sources, configurez-le avec ENABLED_LOCAL_INFILE désactivé ou activé en fonction du choix des clients ne prévoyant pas d'arrangements explicites, la fonctionnalité LOCAL étant désactivée ou activée, respectivement.
    • Les programmes clients qui utilisent l'API C peuvent contrôler le chargement des données de chargement de manière explicite en appelant mysql_options () pour désactiver ou activer l'option MYSQL_OPT_LOCAL_INFILE. Voir Section 28.7.7.50, «mysql_options ()».
    • Pour le client mysql, le chargement de données locales est désactivé par défaut. Pour le désactiver ou l'activer explicitement, utilisez l'option --local-infile = 0 ou --local-infile [= 1].
    • Pour le client mysqlimport, le chargement de données locales est désactivé par défaut. Pour le désactiver ou l'activer explicitement, utilisez l'option --local = 0 ou --local [= 1].
    • Si vous utilisez LOAD DATA LOCAL dans des scripts Perl ou d'autres programmes lisant le groupe [client] à partir de fichiers d'options, vous pouvez ajouter un paramètre d'option local-infile à ce groupe. Pour éviter les problèmes pour les programmes qui ne comprennent pas cette option, spécifiez-la en utilisant le préfixe loose:

      Code : Sélectionner tout
      1
      2
      [client]
      loose-local-infile=0
      ou

      Code : Sélectionner tout
      1
      2
      [client]
      loose-local-infile=1
    • Dans tous les cas, l'utilisation réussie d'une opération de chargement LOCAL par un client nécessite également que le serveur l'autorise.



Serveur MySQL malveillant facilement disponible

Dans la communauté de la sécurité, certaines personnes ont fait une liste des scénarios d'utilisations possibles d'un serveur MySQL malveillant. Les clés SSH volées et les détails d’accès pour les portefeuilles de crypto-monnaie étaient les premiers sur la liste.

Selon le chercheur en sécurité Willem de Groot, les attaques de Magecart d'octobre 2018 ont profité de la faille MySQL pour injecter dans les sites commerciaux du code permettant de voler les détails de carte de paiement à la caisse.

Du code pour un serveur malicieux MySQL est disponible sur GitHub depuis cinq ans. Il n’est donc pas surprenant que les cybercriminels l’utilisent dans leurs attaques.


Dans un billet de blog publié la semaine dernière, de Groot explique comment des escrocs ont utilisé cette vulnérabilité pour extraire des détails sensibles à l'aide d'Adminer, un outil de gestion de bases de données PostgreSQL et MySQL.

Le but des attaquants semble être de voler un fichier ('local.xml') où la plateforme de commerce Magento stocke son mot de passe de base de données. Cela était possible sur les sites Web exécutant une version vulnérable d'Adminer (les versions 4.3.1 à 4.6.2 étaient affectées par le bogue). Les administrateurs doivent passer à une version plus sûre du produit, au moins 4.6.3.

Sources : dev MySQL, blog de Groot

Voir aussi :

PureBasic 5.70 beta 2 est disponible, avec l'ajout de MySQL et MariaDB !
Emploi développeur 2017 : les SGBD les plus demandés et les mieux payés, MySQL, MongoDB et PostgreSQL plus demandés mais MongoDB et DB2 mieux payés
MySQL 8.0 est disponible, le SGBD se dote de nouvelles fonctionnalités SQL, de sécurité, NoSQL et JSON et est jusqu'à deux fois plus performant
MySQL 8.0 RC1 est disponible avec des améliorations en profondeur marquées par le support d'Unicode 9, des CTE, des fonctions Window et plus encore

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

Avatar de Refuznik
Membre averti https://www.developpez.com
Le 22/01/2019 à 13:29
On sait si ça touche aussi MariaDB ?
1  0 
Avatar de Artemus24
Expert éminent sénior https://www.developpez.com
Le 14/04/2019 à 15:54
Salut à tous.

Citation Envoyé par vodkline
Il me semble que non
C'est faux ce que vous dites :
--> https://mariadb.com/kb/en/library/lo...d-data-infile/

On lit :
In releases after MariaDB 5.5, LOAD DATA INFILE is unsafe for statement-based replication.
Si vous ne désirez pas effectuer des chargements de fichiers à partir de cette commande, sous MariaDB, il suffit de la désactiver :
--> https://mariadb.com/kb/en/library/se.../#local_infile

La bonne pratique est de faire en sorte que la base de données ne soit pas accessible de l'extérieur, même avec un MySql (ou MariaDB pirate).
C'est pourquoi, on place les bases de données sur un disque autre que celui du serveur MySql (ou MariaDB) avec des permissions qui sont contrôlées par un responsable système autre que le DBA.
Et tous les accès se feront au travers du serveur MySql (ou MariaDB) avec les permissions attribuées par le responsable système.

Donc oui le problème est connu depuis fort longtemps, mais il existe des bonnes pratiques que certains semblent ne pas connaitre.
On retrouve le même problème dans tous les serveurs à partir du moment où l'on ne gère pas la sécurité des accès aux données.
Ce n'est pas parce que MySql permet de faire beaucoup de choses contraire au bon sens, qu'il faut faire n'importe quoi avec.

@+
0  0 
Avatar de vodkline
Nouveau membre du Club https://www.developpez.com
Le 13/04/2019 à 5:11
Il me semble que non
0  1