Journal Fin du monde en vue ?

Posté par  (site Web personnel) . Licence CC By‑SA.
Étiquettes :
-47
13
sept.
2016

Il y a quand meme des points qui me laisse dubitatif, qu est ce que pense la communauté linuxfrienne ?

http://www.phoronix.com/scan.php?page=news_item&px=MySQL-Crit-0-Day

http://www.nextinpact.com/news/101344-mysql-chercheur-devoile-deux-failles-0-day-critiques.htm#/comment/5736348

http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html

  • # faudrait donner quelques explications.

    Posté par  . Évalué à 10.

    Il y a quand meme des points qui me laisse dubitatif

    Pas autant que ce journal bookmark.

    qu est ce que pense la communauté linuxfrienne ?

    Que ton journal est à mettre à la poubelle ?

    • [^] # Re: faudrait donner quelques explications.

      Posté par  (site Web personnel) . Évalué à -10. Dernière modification le 13/09/16 à 12:26.

      explication de quoi ?
      Qu'une boite a trouvé un 0 day remote root exploit en mysql, ca te parait pas assez explicite ?

      Et non je ne comprend pas toute la fameuse faille surtout comment il reload un mysql avec un fichier de conf "custom" en remote, donc je ne detaillerais pas la demarche ni la commenterais sous reserve de dire des betises.

      Si ya vraiment un zero day exploit sur mysql, c'est un peu le cataclysme sur le web non ? c'est pas vraiment marginal comme techno.

      • [^] # Re: faudrait donner quelques explications.

        Posté par  (site Web personnel) . Évalué à 10.

        Si ya vraiment un zero day exploit sur mysql, c'est un peu le cataclysme sur le web non ?

        Seulement sur les MySQL qui permettent de se connecter directement en TCP à partir d'Internet.
        Généralement, un tel accès n'est pas disponible.

        https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

      • [^] # Re: faudrait donner quelques explications.

        Posté par  . Évalué à 7.

        Ca dépend des détails de l'exploit, mais en règle général la base mysql n'est pas exposée sur le net.

        Tu as du code qui fait l'interface entre la base et le client. Et ce code doit au minimum nettoyer et vérifier ses entrées pour construire des requêtes SQL ensuite, donc ta base est rarement exposée à des requêtes arbitraires. Donc c'est gênant, mais pas forcément cataclysmique. C'est par contre potentiellement très gênant pour des hébergeurs comme Free qui t'offrent une base SQL, pas connectée au net potentiellement mais partagée entre des utilisateurs qu'on veut bien segmenter. Si un utilisateur utilise l'exploit il à accès aux données des autres utilisateurs.

        • [^] # Re: faudrait donner quelques explications.

          Posté par  . Évalué à 9.

          […]donc ta base est rarement exposée à des requêtes arbitraires.

          Si tu es sujet à de l'injection SQL alors tu avais déjà un problème :)

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: faudrait donner quelques explications.

            Posté par  (site Web personnel) . Évalué à 1.

            Ça n'a rien a voir, l'injection SQL permet a un attaquant d'attaquer une application via sa base de donnée.

            Ici le cas de figure est un abonné free qui attaque directement la base de donnée pour avoir un accès privilégié sur les serveurs de free et donc faire plein de choses qu'il n'aurait pas pu faire sinon.

            • [^] # Re: faudrait donner quelques explications.

              Posté par  . Évalué à 3.

              Oui oui on est d'accord. La phrase que je cite ne parle pas de base mutualisée que Free le fait (du moins c'est ce que j'avais compris).

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: faudrait donner quelques explications.

          Posté par  . Évalué à 4.

          au minimum nettoyer et vérifier ses entrées

          Mission impossible. Et aussi, cette façon de faire est terriblement obsolète et a toujours été une mauvaise idée dès le départ.

          Car n'importe quelle entrée est potentiellement valide, peu importe quels filtres tu mets dessus.

          Et de toutes façons, ça fait longtemps qu'on fait quelque chose de beaucoup plus simple et intelligent à la place ( => Prepared Statements)

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: faudrait donner quelques explications.

            Posté par  . Évalué à -1. Dernière modification le 14/09/16 à 22:39.

            J’utilise les prepared statements, je sais que c’est plus sûr, c’est aussi plus pratique à coder et très souvent plus performant. C’est inévitable de passer par là en faisant du SQL. Cependant je me suis toujours poser une question.

            Prepared statements are resilient against SQL injection, because parameter values, which are transmitted later using a different protocol, need not be correctly escaped. If the original statement template is not derived from external input, SQL injection cannot occur.

            Les variables que l’on va « jouer » contre ce template dérivent bien bien d’une source extérieure… Seulement le SGBD va pouvoir… ne pas se faire avoir… car il a d’un côté un modèle et de l’autre une liste de paramètres. On se repose sur l’implémentation du SGBD (et aussi des bibliothèques que l’on utilise).

            Cela dit, implémenter ce mécanisme coté code ne semble pas insurmontable. Si on utilise des chaînes modèles (qui peuvent même être des constantes) avec des placeholders et que l’on "sanitize" chaque variable individuellement on se met à l’abris des injections SQL.

            Évidemment après si on construit sa requête à coup de simples concaténations à l’arrache, c’est sûr…

            • [^] # Re: faudrait donner quelques explications.

              Posté par  (site Web personnel) . Évalué à 4.

              C'est peut-être juste un problème de nomenclature mais j'ai l'impression que tu comprends mal ce que tu cites. En très gros :

              ça c'est vulnérable à Bobby Tables :

              var query = "select * from users where id = " + params.id;

              tu peux le corriger avec des prepared statements comme ça :

              var query = new PreparedStatement("select * from users where id = ?").setParams([params.id]);

              Ce que ce que tu grasses dit c'est que tu te flingues le pied gauche après avoir sauvé le pied droit en faisant ça :

              var query = new PreparedStatement("select " + params.fields + " from users where id = ?").setParams([params.id]);

              Bien qu'une très mauvaise relecture du code dirait "ah c'est bien il utilise un PreparedStatement c'est sécurisé".

              • [^] # Re: faudrait donner quelques explications.

                Posté par  . Évalué à 2.

                var query = "select * from users where id = " + params.id;

                Je pensais plus à ce genre de code :

                $query = vsprintf("INSERT INTO table (f1,f2) VALUES (%d, %d)", $array);

                Il me semble que même si on a laissé un ';drop table students' dans l’un des éléments du tableau (déjà il faut le faire…) ça ne va pas fonctionner.

                • [^] # Re: faudrait donner quelques explications.

                  Posté par  (site Web personnel) . Évalué à 1. Dernière modification le 15/09/16 à 14:47.

                  Je suppose qu'une bonne implémentation d'interpolation de chaîne refusera de parser ";drop table" comme entier, oui, mais d'une c'est galère d'écrire le bon format pour chaque paramètre par rapport aux points d'interrogation simples d'un prepared statement (et si tu attends une chaine comme paramètre bah t'es baisé, "; drop table" est bien une chaine valide) et de deux ton exemple c'est pas un prepared statement donc je vois pas le rapport avec le sujet des prepared statement :) (sauf si tu comptais construire un prepared statement à partir de $query mais alors tu n'as pas compris les prepared statements).

                  • [^] # Re: faudrait donner quelques explications.

                    Posté par  . Évalué à 2. Dernière modification le 15/09/16 à 17:29.

                    points d'interrogation simples d'un prepared statement (et si tu attends une chaine comme paramètre bah t'es baisé, "; drop table" est bien une chaine valide)

                    C’est bien pour ça que j’ai parlé de vérifier les valeurs des variables…

                    Si j’ai envoyé la requête préparée 'UPDATE table SET truc=? WHERE id=?' et qu’ensuite j’envoie "'; drop table machin;" comme valeurs, si le SGBD ne contrôlait pas la tronche des paramètres qu’il passe à la requête préparée on se retrouverait bien à exécuter une truc (du genre) 'UPDATE table SET truc=''; drop table machin;' WHERE id=''; drop table machin;''

                    ton exemple c'est pas un prepared statement donc je vois pas le rapport avec le sujet des prepared statement :)

                    Je sais que ce n’est pas un prepared statement et qu’un prepared statement ne consiste pas simplement à répéter une requête avec des paramètres différents depuis le code applicatif.

                    Je ne dis pas qu’on peut reproduire l’ensemble des fonctionnalités des prepared statement côté applicatif (c’est faux, puisse qu’il s’agit d’abord d’une fonctionnalité du moteur SQL), donc que l’on pourrait s’en passer, je dis simplement que la fonctionnalité "je me protège des injections SQL" peut quant à elle tout à fait l’être… Néanmoins je n’y vois aucun avantage, effectivement…

      • [^] # Re: faudrait donner quelques explications.

        Posté par  . Évalué à 10.

        explication de quoi ?
        Qu'une boite a trouvé un 0 day remote root exploit en mysql, ca te parait pas assez explicite ?

        Ou est la phrase dans ton journal ? Nulle part. Et quel est le rapport avec la fin du monde ? Désolé pour toi mais nous ne sommes pas dans ton cerveau et ne pouvons savoir ce que tu penses.

        Une courte phrase du style "une faille 0 days a été découverte dans mysql", c'était déjà mieux. Tu aurais mis ça en titre, je n'aurais rien eu à dire. Mais là on ne comprend rien à ce que tu veux dire : quel est le rapport avec la fin du monde, et pourquoi es-tu dubitatif

        Et non je ne comprend pas toute la fameuse faille surtout comment il reload un mysql avec un fichier de conf "custom" en remote, donc je ne detaillerais pas la demarche ni la commenterais sous reserve de dire des betises.

        Ce n'est pas ce qui est demandé ici.

        Si ya vraiment un zero day exploit sur mysql, c'est un peu le cataclysme sur le web non ? c'est pas vraiment marginal comme techno.

        Alors pourquoi ne pas le dire dans ton journal ?

      • [^] # Re: faudrait donner quelques explications.

        Posté par  . Évalué à 10.

        … mais tu ne l'as pas écrit, comme le fait que les mises à jour de sécurité pour MariaDB sont disponibles depuis longtemps, et qu'il n'y a qu'Oracle qui n'aie pas daigné les fournir sous 40 jours. Tu vois, il y avait de la matière!

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: faudrait donner quelques explications.

        Posté par  (site Web personnel) . Évalué à 5. Dernière modification le 13/09/16 à 14:53.

        Si ya vraiment un zero day exploit sur mysql, c'est un peu le cataclysme sur le web non ?

        Non.
        D'une parce qu'il faut laisser le MySQL en public, ce qui est rare donc ça limite la portée.
        De deux car le monde ne tourne pas autour de MySQL loin de la, ni de l'informatique loin de la (la pub : beaucoup de chose s'achète avec Mastercard, mais il y a le reste). La faille serait sur Microsoft Windows toutes versions et Android en même temps que la fin du monde ne serait pas là non plus.
        De trois parce que MariaDB a déjà corrigé la faille (tout le monde ne s'appelle pas "Oracle je m'en tant que c'est pas public") et que pas mal de monde a quitté MySQL depuis Oracle pour aller vers le "vrai" MySQL (comme du monde a arrêté de regarder le Petit Journal pour aller retrouver le Quotidien, dans les 2 cas c'est une bande qui a déménagé d'un employeur chiant à un autre employeur tout en gardant son âme), "petit" exemple.

        Bref, faudrait lire les liens que tu pointes et relativiser par rapport à la vie en dehors de ta chambre, tu comprendras peut-être la raison du gros moinssage d'un journal pire que bookmark et faux.

        • [^] # Re: faudrait donner quelques explications.

          Posté par  . Évalué à 7.

          De deux car le monde ne tourne pas autour […] de l'informatique loin de la […]

          (désolé de tronçonner ta phrase, mais je ne pense pas en changer le sens)

          J'ai l'impression que si au contraire. Du moins ça dépend de ce qu'on entend par « le monde tourne autour ». Dans les pays riches, la société de l'information est omniprésente et j'ai l'impression qu'on développe une dépendance forte à tout cela. Ce n'est pas qu'une histoire de réseaux sociaux. De manière direct, nous nous sommes créé un besoin de nous informer partout tout le temps1. De manière indirect, nous faisons dépendre de plus en plus de choses de l'informatique (si là maintenant dans l'instant ta carte bancaire disparaît et que ta banque t'annonce 2 ou 3 semaines avant que tu la reçoive par exemple ? - je sais les allemands sont très liquide il paraît, mais ils retirent aux guichets ou aux distributeurs ? -).

          Bien sûr on survivrait à l’absence de l'informatique, on en a pas un besoin physionomique, mais ça serait dans la douleur.


          1. dédicace aux pubs de voitures ou de nourriture qui essaient de vendre leur produit en parlant de réseaux sociaux ou en te vendant des tablettes par exemple… 

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: faudrait donner quelques explications.

        Posté par  . Évalué à 2.

        t'accède souvent à MySQL par le web ?

  • # Postgresql

    Posté par  . Évalué à 7.

    Il est temps de passer à Postgresql !

  • # Bonjour

    Posté par  (site Web personnel) . Évalué à 6.

    Bonjour,

    quel est le rapport entre la fin du monde et 3 urls qui te laissent dubitatives ?

    • [^] # Re: Bonjour

      Posté par  . Évalué à 10.

      La fin justifie les (journaux) moyens?

  • # je pense que...

    Posté par  . Évalué à 1.

    Je pense que tout ceci est bien succinct.

    La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

  • # Ouf !!!

    Posté par  (site Web personnel) . Évalué à 8.

    J'ai cru que Apple retirai son dernier smartphone …

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.