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
Journal Fin du monde en vue ?
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
# faudrait donner quelques explications.
Posté par totof2000 . Évalué à 10.
Pas autant que ce journal bookmark.
Que ton journal est à mettre à la poubelle ?
[^] # Re: faudrait donner quelques explications.
Posté par Sylvain (site web personnel) . Évalué à -10. Dernière modification le 13 septembre 2016 à 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 Sébastien Maccagnoni (site web personnel) . Évalué à 10.
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.
[^] # Re: faudrait donner quelques explications.
Posté par Fulgrim . É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 barmic . Évalué à 9.
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 Mildred (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 barmic . É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 xcomcmdr . Évalué à 4.
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 Marotte ⛧ . Évalué à -1. Dernière modification le 14 septembre 2016 à 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.
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 Sufflope (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 :
tu peux le corriger avec des prepared statements comme ça :
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 :
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 Marotte ⛧ . Évalué à 2.
Je pensais plus à ce genre de code :
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 Sufflope (site web personnel) . Évalué à 1. Dernière modification le 15 septembre 2016 à 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 Marotte ⛧ . Évalué à 2. Dernière modification le 15 septembre 2016 à 17:29.
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;''
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 totof2000 . Évalué à 10.
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
Ce n'est pas ce qui est demandé ici.
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 Zenitram (site web personnel) . Évalué à 5. Dernière modification le 13 septembre 2016 à 14:53.
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 barmic . Évalué à 7.
(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.
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 steph1978 . Évalué à 2.
t'accède souvent à MySQL par le web ?
# Postgresql
Posté par Xavier Poinsard . Évalué à 7.
Il est temps de passer à Postgresql !
# Bonjour
Posté par Ramón Perez (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 calandoa . Évalué à 10.
La fin justifie les (journaux) moyens?
# je pense que...
Posté par Nibel . É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 Christophe B. (site web personnel) . Évalué à 8.
J'ai cru que Apple retirai son dernier smartphone …
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.