Discussion :

[Stéphane le calme]

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

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.

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 - Visualiser dans une fenêtre à part

    1
    2
    [client]
    loose-local-infile=0

    ou
    
    

    Code :

    Sélectionner tout - Visualiser dans une fenêtre à part

    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

[Refuznik]

On sait si ça touche aussi MariaDB ?

[vodkline]

Il me semble que non

[Artemus24]

Salut à tous.

Il me semble que non

C'est faux ce que vous dites :
--> https://mariadb.com/kb/en/library/load-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.

@+