Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    4 179
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 4 179
    Points : 109 865
    Points
    109 865

    Par défaut Une faille dans la conception de MySQL permet à des serveurs malveillants de voler des fichiers à des clients

    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.

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

    Nom : groot.png
Affichages : 2366
Taille : 32,9 Ko

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre habitué
    Profil pro
    Inscrit en
    mars 2006
    Messages
    78
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2006
    Messages : 78
    Points : 184
    Points
    184

    Par défaut

    On sait si ça touche aussi MariaDB ?

Discussions similaires

  1. Réponses: 2
    Dernier message: 19/06/2016, 14h15
  2. Une faille dans iOS 4.1 permet un vol des données personnelles
    Par Katleen Erna dans le forum Actualités
    Réponses: 10
    Dernier message: 28/10/2010, 11h47
  3. Réponses: 10
    Dernier message: 28/10/2010, 11h47
  4. Une faille dans QuickTime permet une attaque par drive-by sur IE
    Par Katleen Erna dans le forum Actualités
    Réponses: 1
    Dernier message: 31/08/2010, 19h20
  5. Réponses: 1
    Dernier message: 07/02/2010, 16h23

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo