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 842
    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 842
    Points : 125 711
    Points
    125 711
    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 : 34006
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 averti
    Profil pro
    Inscrit en
    mars 2006
    Messages
    112
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2006
    Messages : 112
    Points : 320
    Points
    320
    Par défaut
    On sait si ça touche aussi MariaDB ?

  3. #3
    Nouveau membre du Club
    Profil pro
    Inscrit en
    novembre 2010
    Messages
    203
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2010
    Messages : 203
    Points : 38
    Points
    38
    Par défaut
    Il me semble que non

  4. #4
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    février 2011
    Messages
    4 165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 79
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : février 2011
    Messages : 4 165
    Points : 12 371
    Points
    12 371
    Par défaut
    Salut à tous.

    Citation Envoyé par vodkline
    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.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

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