Salut nal'
Une faille sur le WPA2 semble avoir été découverte. Un Github et un site web ont été mis en place, ils pourraient contenir plus d'informations dans la journée. Le 1er novembre, une présentation plus détaillée aura lieu durant une conférence ACM à Dallas. cf. https://www.macg.co/ailleurs/2017/10/une-faille-dans-le-wpa2-met-le-wi-fi-en-danger-100079 pour plus de détail.
ça t'inquiète cette histoire de wpa2 cracké ou bien tu penses que c'est du vent ?
Tu vas mettre à jour tes imprimantes et tes milliers gadgets connectés ? Comment parce que c'est pas si libre ? ;-)
# commentaire link
Posté par octane . Évalué à 10.
Bonjour,
pourquoi ne pas donner le bon lien vers le bon site et le bon papier?
https://www.krackattacks.com/ et https://github.com/vanhoefm/papers/blob/gh-pages/ccs2017.pdf
Grosso modo, faut il tous courir les bras en l'air en disant que c'est la fin du monde? Bah apparemment non.
Si tu utilises Android 6.0, tu as plus chaud aux fesses que les autres. Pour les autres justement, patchez doucement. Au pire, un gars peut injecter et déchiffrer des trames clients. Au mieux il peut juste déchiffrer quelques trames du client.
De toute façon, tout le monde utilise un proto chiffré au dessus du wifi, non? [:trollface:]
[^] # Re: commentaire link
Posté par Albert_ . Évalué à 3.
OpenBSD se fait detruire sur la gestion du probleme … et cela a des effets a long terme. La prochaine fois ils auront 2h pour patcher le probleme! Bien joue!
[^] # Re: commentaire link
Posté par calandoa . Évalué à 10.
C'est rigolo, le premier message descend Android, le second descend BSD, et qu'est ce qu'on voit dans les premières ligne du site ? « our key reinstallation attack is exceptionally devastating against Linux and Android 6.0 or higher. »
Ces oublis n'ont bien sûr strictement rien à voir avec le fait qu'on soit sur linuxfr…
[^] # Re: commentaire link
Posté par Albert_ . Évalué à 7.
Les deux utilisent wpa_supplicant qui est en effet le pire sur le sujet mais bon si on lit en details:
Et encore:
Donc en gros tout le monde est tombe dans le piege, certains plus que d'autres (wpa_supplicant etant au top de la hierarchie).
Ce que je mentionnais de OpenBSD c'est:
Apres si tu trouves ca cool de mettre TOUS les autres systemes en danger c'est sympa, un petit peu egoiste tout de meme non? Quoiqu'il en soit, OpenBSD sera maintenant averti en … dernier.
[^] # Re: commentaire link
Posté par Christophe . Évalué à 5.
Ici OpenBSD n'y est pour rien !
C'est lui qui a autorisé OpenBSD à faire la correction en avance. En rétrospective il regrette, sauf que sans l'autorisation de publier la correction, est-ce qu'OpenBSD l'aurait quand même fait ? Rien n'est moins sûr…
[^] # Re: commentaire link
Posté par gouttegd . Évalué à 10.
Après que Theo de Raadt s’est plaint. Et au final, OpenBSD a gagné quoi dans l’histoire ?
M. Vanhoef: On va annoncer d’ici six semaines une vulnérabilité critique. [Détails de la vulnérabilité, et proposition de fix.] Ne publiez pas le fix tout de suite SVP.
T. de Raadt: C’est très décourageant de nous demander d’attendre un mois avant de publier un correctif !
M. Vanhoef: Bon OK, désormais on vous préviendra après tous les autres, quelques jours seulement avant de rendre la vulnérabilité publique, comme ça vous n’aurez pas à attendre longtemps.
[^] # Re: commentaire link
Posté par anaseto . Évalué à 8.
Plus de détails dans ce commentaire par un développeur. En gros, l'embargo a été étendu : OpenBSD a respecté le premier délai d'un mois, mais pas l'extension après mettre au courant CERT et donc (d'après le commentaire) les agences gouvernementales des US.
[^] # Re: commentaire link
Posté par Psychofox (Mastodon) . Évalué à 7. Dernière modification le 16 octobre 2017 à 16:35.
En même temps 1 mois c'est déjà extremement long pour ce type de failles. Une boite qui n'est pas capable de fournir et pousser un patch dans un délai d'un mois sur une faille aussi critique va de toute façon demander des délais à l'infini. Ce n'est pas rendre service aux utilisateurs que de cacher ces failles aussi longtemps. On est en octobre tout de même.
Perso j'ai juste envie de jeter mon tuer mon smartphone à coup de pioche car je n'ai aucune garantie que le fabricant fournira une update de firmware rapidement.
[^] # Re: commentaire link
Posté par gouttegd . Évalué à 4.
Ça ne me paraît pas déraisonnable pour une faille qui affecte de multiples projets et éditeurs.
En 2008, l’embargo autour de la « faille Kaminsky » dans les implémentations DNS avait été beaucoup plus long (si je me souviens bien, au moins de mars à août).
[^] # Re: commentaire link
Posté par Psychofox (Mastodon) . Évalué à 8.
Ce n'est pas parce qu'on la déjà fait qu'on se rend service à faire des embargos aussi long à chaque fois. D'autant plus que pendant cette période on n'a aucune idée des éventuelles fuites qui peuvent se faire entre ceux qui savent et des tiers hostiles.
[^] # Re: commentaire link
Posté par Renault (site web personnel) . Évalué à 10.
Quand tu es une entreprise, type Microsoft, Samsung ou Apple, avec des milliards d'utilisateurs dans le monde, plusieurs déclinaisons de logiciels / matériels à tester alors que tes utilisateurs payent chers pour avoir un produit qui marche, 1 mois ce n'est pas très long pour faire le travail nécessaire et garantir la qualité du correctif (en plus d'identifier le problème et le corriger). Car bon, si c'est pour envoyer à l'arrache un correctif qui fait planter le téléphone ou l'ordinateur d'un utilisateur sur X, ce n'est pas très professionnel. Et cela peut arriver.
Car admettons, si le correctif d'OpenBSD ne fonctionne pas partout, je pense que Theo va envoyer un gros RTFM à ces utilisateurs pour corriger cela à la main, ou rapporter les bogues car c'est lié éventuellement au matériel ou à une configuration spécifique du logiciel. Mais pour l'utilisateur lambda de certaines entreprises, ce n'est pas envisageable. Ce travail doit être fait avant.
[^] # Re: commentaire link
Posté par Psychofox (Mastodon) . Évalué à 1. Dernière modification le 16 octobre 2017 à 20:02.
T'es pas obligé de tout faire planter. Tu peux aussi informer tes utilisateurs et les inciter à désactiver le wifi en attendant.
Après chacun est responsable de faire le choix entre "envoyer du traffic à peine aussi sécurisé que si ça passait en clair" via le wifi ou se passer du wifi dans l'intervalle de la sortie du patch officiel.
Et entre laisser des millions de devices vulnérables dans la nature où avoir un pourcentage négligeable de dommages collatéraux comem des dysfonctionnements dans la nature je sais ce qui me semble le plus responsable, même si ce n'est pas ce qui est le plus joli en terme d'image de marque pour l'utilisateur non informé.
[^] # Re: commentaire link
Posté par Renault (site web personnel) . Évalué à 7.
Sachant que pour certains (et même beaucoup de gens), le Wifi est le seul moyen d'accéder à Internet, ce n'est pas réaliste.
Le trafic de ce que j'ai compris n'est pas envoyé en clair, même si un pirate y a accès, il ne peut pas outrepasser les solutions type HTTPS. Sachant que le HTTPS et autres protocoles de sécurité sont de plus en plus employés, cela reste moins grave que ce genre d'attaques par le passé.
De plus, si la faille existe, aucune trace de son utilisation a été constatée, et dévoiler le correctif directement aurait porté à la connaissance de tous les vilains de comment procéder pour l'exploiter. Je ne sais pas ce qui est le mieux, mais tout dévoiler le plus vite possible n'est pas forcément la meilleure solution.
[^] # Re: commentaire link
Posté par Psychofox (Mastodon) . Évalué à -1.
Je n'ai pas dis dévoiler immédiatement. J'ai dis pas la peine d'attendre 4 mois, on écris des patchs en moins de temps que cela.
[^] # Re: commentaire link
Posté par be_root . Évalué à 6.
Correction : il faut décaler la virgule qui suit le mot "marche" de deux mots vers la droite. Merci. :)
Il se prend pour Napoléon, son état empire.
[^] # Re: commentaire link
Posté par Zenitram (site web personnel) . Évalué à 3.
Il va falloir argumenter, avec une bonne crédibilité, pour affirmer que c'est long quand d'autres disent que c'est court, et que ces autres me semblent plus crédibles que toi de par leurs responsabilités à gérer des millions/milliards de terminaux. Exemple avec une bataille entre Google et Microsoft (tldr: 7 jours si vulnérabilité exploitée, sinon 90 jours), je trouve ça très long mais je leur fais confiance pour connaitre plus que moi la problématique.
Bah… C'est du WiFi. Perso, je suis sur es dizaines de WiFi publics donc déjà sans WPA ou autre, toutes mes connections sont sécurisées (IMAPS, SMTPS, HTTPS…) justement parce que en pratique tu es déjà sans cette couche, et qu'il faut que ton tel (ou autre) soit protégé avec autre chose. Le problème n'est pas ton téléphone, pas d'urgence pour lui, plutôt l'idée que quelqu'un utilise ta connexion Internet perso. Enfin, si j'ai bien compris, corrigez moi si j'ai loupé un épisode.
SSL everywhere!
[^] # Re: commentaire link
Posté par gouttegd . Évalué à 7.
Hum, non, si j’ai bien compris, la faille présentée (même dans sa pire version, celle qui affecte wpa_supplicant et donc les téléphones Android ≥ 6) ne permet pas à un tiers d’utiliser ta connexion.
Elle lui permet (potentiellement) de déchiffrer tout ou partie du traffic, et d’injecter ses propres paquets fabriqués dans le traffic (ouvrant probablement la porte à toutes sortes d’attaques — je pense par exemple à tous ces sites dont la page de connexion est envoyée en clair, et qui ne passent en https qu’après l’authentification de l’utilisateur :facepalm: ), mais pas de s’authentifier comme un utilisateur légitime du réseau WiFi sur lequel l’attaque a lieu.
C’est notamment pour ça que les auteurs ne recommandent pas de changer les mots de passe des points d’accès, parce que c’est inutile — ils ne sont pas compromis par cette faille.
[^] # Re: commentaire link
Posté par Faya . Évalué à 2.
J'ai déjà vu des trucs pas nets sur le web mais ça jamais …
Le dev/admin aurait pris la peine d'installer un certificat mais pour ne l'utiliser qu'après l'authentification !? Je demande un exemple
[^] # Re: commentaire link
Posté par oinkoink_daotter . Évalué à 4.
linuxfr quand tu t'y connectes en httpsanss, il me semble.
[^] # Re: commentaire link
Posté par Faya . Évalué à 5.
Quand je me connecte en http sur linuxfr, je reste en http (testé à l'instant). Il ne me bascule pas en https après authentification.
[^] # Re: commentaire link
Posté par gouttegd . Évalué à 6.
C’est (malheureusement) assez fréquent. Troy Hunt (le développeur derrière haveibeenpwned.com) a répertorié quelques exemples.
[^] # Re: commentaire link
Posté par Gof (site web personnel) . Évalué à 4.
SSL c'est dépassé. Il faut utiliser TLS maintenant.
[^] # Re: commentaire link
Posté par Anonyme . Évalué à 2.
Y a vraiment des gens qui n’utilisent pas STARTTLS ?
[^] # Re: commentaire link
Posté par Firwen (site web personnel) . Évalué à -1.
Tous les gens qui savent que STARTTLS est vulnerables aux attacks MitM ?
[^] # Re: commentaire link
Posté par Moonz . Évalué à 3.
Seulement dans les cas où SMTPS est de toute façon impossible à utiliser.
[^] # Re: commentaire link
Posté par dani . Évalué à 1.
Aha. Merci. J'ai ri !
[^] # Re: commentaire link
Posté par freem . Évalué à 4.
pourquoi wpa_supplicant est-il le pire?
Est-ce juste sur ce point ou de maniere generale?
Il y aurait des outils alternatifs portes sur les plus gros os "posix" (dans mon cas linux, mais vu que j'ai l'intention un jours de passer a net ou open bsd…)?
Desole pour les questions, mais moi et la secu, ca fait malheureusement 2, si ce n'est plus…
[^] # Re: commentaire link
Posté par gouttegd . Évalué à 10.
Si j’ai bien compris :
Parce que lorsqu’il reçoit le 3ème message de la poignée de main (le message qui établit la clef de chiffrement) plusieurs fois de suite, wpa_supplicant ré-initialise la clef de chiffrement à zéro, ce qui rend le déchiffrement du traffic ultérieur trivial.
Les autres implémentations laissent la clef inchangée, mais avec un nonce prévisible, ce qui rend possible des tentatives de déchiffrement sur le traffic ultérieure, mais pas de manière aussi triviale que dans le cas précédent.
Le comportement de wpa_supplicant est apparemment le résultat d’une ambiguïté dans le standard (“This vulnerability appears to be caused by a remark in the Wi-Fi standard that suggests to clear the encryption key from memory once it has been installed for the first time.”).
[^] # Re: commentaire link
Posté par Sufflope (site web personnel) . Évalué à 9.
J'espère que le standard est plus ambigu que ça, parce que je vois pas comment on passe (sans être un guignol) de "effacer une clé de chiffrement de la mémoire quand on en a plus besoin" à "continuer à fonctionner comme si de rien n'était mais avec 0000 comme clé et être content de soi".
[^] # Re: commentaire link
Posté par claudex . Évalué à 4.
En même temps, ça fait 10 ans que le code est là et que personne ne s'est plaint. Du coup, ça ne dérange pas tant de monde que ça.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: commentaire link
Posté par ckiller . Évalué à 0.
je croyais que le code libre est trop bien audité parce que libre.
ca fait quand même peur que ce genre de code ne soit pas auditer sérieusement
[^] # Re: commentaire link
Posté par Renault (site web personnel) . Évalué à 8.
Le libre c'est bien car tu peux l'auditer toi même, ou payer quelqu'un pour le faire. Mais ce n'est pas magique, ce n'est pas parce que c'est libre que tout le monde relis le code.
Avec le proprio tu es obligé de faire confiance à l'éditeur sur le sujet, à moins d'être un gros client ou un gouvernement (qui peuvent se permettre en général de regarder le code source d'un code proprio).
[^] # Re: commentaire link
Posté par groumly . Évalué à -8.
Et ouais, le libre c’est génial parce que c’est quelqu’un d’autre qui fait la vérification (ou pas).
Le proprio, ça pue, parce que c’est quelqu’un d’autre qui fait la vérification (ou pas).
En pratique, c’est kifkif, personne n’audite le code, et les deux ont des failles béantes publiées et non decouverte/corrigées pendant des années. Faut arrêter de prendre ses vessies pour des lanternes.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: commentaire link
Posté par Psychofox (Mastodon) . Évalué à 10.
Ben dans le cas ici-présent un chercheur est tombé sur un bout de code qui lui a mis la puce à l'oreille (alors qu'en fait il ne cherchait pas une faille). Ce qui me semble plutôt positif du côté du logiciel libre.
Après ça donne aussi libre accès à toute espèce de margoulin d'aller chercher les failles dans une optique plus hostile mais bon ça peut aussi être fait par reverse engineering de code proprio.
[^] # Re: commentaire link
Posté par Marotte ⛧ . Évalué à 8. Dernière modification le 17 octobre 2017 à 16:26.
Et ouais, le libre c’est génial parce que
c’est quelqu’un d’autre qui faitn’importe qui ayant les compétences peut faire la vérification (ou pas).Le proprio, ça pue, parce que c’est
quelqu’un d’autrel’éditeur qui fait la vérification (ou pas).Donc « kifkif », même en pratique, j’émets quelque réserve.
Tu veux dire des failles non corrigées malgré leur publication ? Tu aurais un exemple d’une telle faille sous OpenBSD ?
[^] # Re: commentaire link
Posté par Albert_ . Évalué à 4.
https://m.slashdot.org/story/332505
Comme quoi libre ou proprio…
[^] # Re: commentaire link
Posté par Sufflope (site web personnel) . Évalué à 4.
C'est quand la dernière fois que tu as fait une revue de code (une revue, comme ça, hein, pas "j'ai un bug alors je fais un rapport" (ce qui est déjà très bien évidemment)) d'un projet qui n'est ni un de tes projets persos ni un projet professionnel pour lequel tu es payé ?
[^] # Re: commentaire link
Posté par claudex . Évalué à 4.
Ben, moi, je ne viens pas dire "j'espère que le développeur avait une bonne raison pour écrire ce bug".
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: commentaire link
Posté par Sufflope (site web personnel) . Évalué à 2.
Quand on pense qu'un bon comportement par défaut pour un soft de chiffrement c'est "continuer silencieusement avec une valeur codée en dur comme clé" vaut peut-être mieux s'adonner à sa passion pour les crèpes qu'à la programmation, finalement.
[^] # Re: commentaire link
Posté par xcomcmdr . Évalué à 4.
Ah ben bravo, maintenant j'ai une grosse envie de crêpe !
Crêpe au fromage, à la rhubarbe, au Nutella, à la framboise, voire à la crêpe.
Mhhh… Miam !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: commentaire link
Posté par Marotte ⛧ . Évalué à 7.
Je vais prendre une crêpe au sucre.
[^] # Re: commentaire link
Posté par windu.2b . Évalué à 7.
Ah non non non, je m'excuse, monsieur, nous ne faisons pas ça ici. Vous vous êtes trompés d'établissement. Vous avez toutes nos crêpes sur la carte.
[^] # Re: commentaire link
Posté par groumly . Évalué à 8.
Vous avez d'la pate? Vous avez du suc'?
Bon ben avec la pate, vous faites une crêpe, et vous mettez du suc' dessus!
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: commentaire link
Posté par Michaël (site web personnel) . Évalué à 4.
Crêpes au citron et sucre, de loin les meilleures! :P
[^] # Re: commentaire link
Posté par calandoa . Évalué à 10.
« J'espère que le standard est plus ambigu que ça […]»
Le problème ici n'est pas le standard, mais l'implémentation de wpa_supplicant qui est tout simplement mauvaise. C'est en fait une malheureuse coïncidence que le type l'ai découvert en même tant que son attaque.
Ce qui se passe:
- message 1 <--, le device reçoit des informations pour dériver sa clé X ;
- message 2 -->, il renvoie d'autres informations ;
- message 3 <--, il reçoit d'autres informations et installe à ce moment la clé X, puis il efface le bloc mémoire temporaire où elle était stockée ;
- […]
- re-message 3 (attaque) <--, il re-installe la clé X, "oubliant" qu'il vient en fait d'effacer ce bloc mémoire.
C'est véritablement un bug. Le développeur en effaçant la mémoire a fait un peu de zèle, et c'est une pratique conseillée dans ce cas pour éviter d'avoir une clé confidentielle inutilement en mémoire qui pourrait être découverte avec une attaque type heartbleed, mais il a oublié ce cas particulier.
Le mieux est l'ennemi du bien pourrait on dire…
Ici la correction assez simple à comprendre, qui rajoute un flag pour se rappeler que la clé a déjà été installée : https://w1.fi/cgit/hostap/log/ « Prevent installation of an all-zero TK »
[^] # Re: commentaire link
Posté par Anonyme . Évalué à 9.
Le commit en question : Prevent installation of an all-zero TK.
[^] # Re: commentaire link
Posté par Albert_ . Évalué à 4.
Dans le papier il est bien spécifié que le comportement de wpa_supplicant est bien pourri sur cette attaque.
# Des explications svp
Posté par Leniwce . Évalué à -10. Dernière modification le 16 octobre 2017 à 17:08.
Bonjour,
J'aimerais bien obtenir un peu plus de details, d'explications au sujet de cet embargo. Comment ce fait-il que les utilisateurs soient pris en otages de la sorte avec la participation du libre ? C'est tout de meme hallucinant autant de mepris, des pratiques de voyou.
attention chérie ça va moinsser
[^] # Re: Des explications svp
Posté par danarmk . Évalué à 10.
Il ne s'agit pas de prendre en otage : une fois une faille découverte, on averti les développeurs concernés, mais pas tout de suite le grand public, afin de laisser le temps aux développeurs de corriger le problème. Ensuite, ou si les développeurs trainent des pieds, on averti tout le monde. Si on avertissait tout le monde dès le début, on prendrait le risque que des personnes mal intentionnées utilisent cette faille, et comme il n'existerait pas encore de correctif, ils auraient la porte grande ouverte.
Ça s'appelle la divulgation responsable, et c'est une pratique standard lors de la découverte de failles ; voir par exemple Responsible disclosure ou Rebooting Responsible Disclosure: a focus on protecting end users
Je laisse des personnes qui savent réellement de quoi elles parlent donner plus de détails :p
[^] # Re: Des explications svp
Posté par Albert_ . Évalué à 3.
Petite question: tu vas en faire quoi de la connaissance de la faille? Tu vas faire un patch et tu vas l'envoyer au projet upstream?
Parceque j'ai comme un doute que pour 99,99999999% des utilisateurs de systeme d'exploitations (vu qu'ils ont tous ete touche) soit capable/interesse de le faire.
[^] # Re: Des explications svp
Posté par wismerhill . Évalué à 7.
Donc, d'après toi il n'y a que 0.7 personnes dans le monde (moins, si on tient compte du fait qu'il y a des gens dans le monde qui n'ont jamais utilisé d'ordinateur) pour régler le problème, pas étonnant que ça ait pris aussi longtemps.
Au moins, il n'y a pas de doute que tu as tapé un chiffre sans réfléchir :-)
[^] # Re: Des explications svp
Posté par paulez (site web personnel) . Évalué à 3.
L'exploiter. L'idée est de permettre de patcher le plus rapidement les systèmes concernées dès l'annonce de la faille. Il faut donc laisser du temps aux nombreux acteurs concernés pour être prêts. Lorsque la faille est annoncée, n'importe qui peut tenter de l'exploiter (car la vulnérabilité est exposée clairement) et donc cela pose un bien plus grand risque pour les systèmes qui n'ont pas été patchés.
[^] # Re: Des explications svp
Posté par gaaaaaAab . Évalué à 4.
je ne pense pas que tu mérites un moinssoyage en règle. La dernière phrase de ton commentaire est très maladroite, puisque tu sautes sur une conclusion sans attendre la réponse à ta demande d'explications.
Mais sur le fond, ton interrogation est légitime. Quand on n'a jamais été confronté aux questions qui se posent dans ce genre de situation, apprendre qu'il y a un délai volontaire entre la découverte de la faille et le déploiement des correctifs, c'est surprenant.
J'espère que les autres réponses à ton message t'ont permis de comprendre pourquoi ça se passe comme ça.
[^] # Re: Des explications svp
Posté par anaseto . Évalué à 6.
Ça peut paraître surprenant, d'autant plus que, même si à peu près tout le monde est d'accord pour l'existence d'un embargo et essayer de prévenir les autres « gentils », c'est plus du tout le cas sur leur longueur, et le système n'est pas parfait.
Parce que plus l'embargo est long, plus il y a des chances qu'il y ait une fuite et que cette fuite puisse être mise à profit sur une longue durée. Et suivant les cas il y a probablement des acteurs qui ne seront pas prévenus parce que trop petits ou pas assez connus, donc la philosophie c'est de faire ce qui est mieux pour la majorité, au potentiel détriment des minorités, qui est une philosophie qui se défend, mais n'est pas universelle non plus.
Et clairement, en fonction des acteurs, un embargo plus ou moins long est plus ou moins pertinent. Pour des logiciels libres, il y a de bonnes chances que les correctifs soient prêts très rapidement et que donc un embargo tout petit suffise aux distributions et, moins de temps on laisse aux potentielles fuites après que les correctifs soient prêts à être distribués, mieux c'est, donc en général l'intérêt d'un embargo long, c'est plutôt pour les gros vendeurs qui, certes représentent beaucoup de clients. Et aussi pour les chercheurs, pour donner plus de médiatisation à leur découverte. Bref, l'intérêt d'un embargo long est varié et inégal et dépend aussi du type de faille, donc s'étonner de ces choses est pour le moins très compréhensible.
# security update
Posté par oliviergiraud . Évalué à 1.
On dirait que la faille est déjà patchée:
wpa (2.4-0ubuntu6.2) xenial-security; urgency=medium
Ça n'a pas trainé
[^] # Re: security update
Posté par claudex . Évalué à 6.
Comme expliqué dans les autres commentaires, ça fait quelques mois que la faille est connue. Elle a justement été annoncée publiquement aujourd'hui pour que les patchs puissent être publiés.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: security update
Posté par Anonyme . Évalué à 8.
Là où ça va trainer c'est chez les nombreux appareils sur Android 6. Ça risque même de trainer indéfiniment sur certains modèles, à part si l'utilisateur est suffisamment expérimenté ou aventurier pour flasher une rom alternative si tant est qu'il en existe pour son appareil.
[^] # Re: security update
Posté par oinkoink_daotter . Évalué à 2. Dernière modification le 17 octobre 2017 à 13:29.
La où ça va traîner, c'est sur les 50% de devices qui ne sont même pas sous Android 6.
…
Bon en même temps, ça vient en plus des vulnérabilités critiques qui sont déjà là, mais bon…
[^] # Re: security update
Posté par Anonyme . Évalué à 1. Dernière modification le 17 octobre 2017 à 22:29.
Bien entendu mais ce bug est censé concerner Android 6 et supérieur donc j'en parle même pas. Mais là est tout l'intérêt d'avoir des appareils avec le moins de pilotes propriétaires possible qui puissent avoir au moins un suivi communautaire.
Sinon niveau stats, ce n'est que par rapport aux appareils qui se sont connectés au Google Playstore pendant cette semaine-là donc c'est une estimation à prendre avec un certain recul.
[^] # Re: security update
Posté par oinkoink_daotter . Évalué à 4.
Pas de confirmation claire. Tout d'abord, il n'y a pas de raison qui font qu'à peu près tout soit vulnérable à ça, et ce depuis toujours et pas l'implémentation de Google pre Android 6, d'autant que wpa_supplicant était déjà dedans en 4.0.4. Et surtout, le papier qui est repris partout n'a pas vraiment l'air d'avoir seulement regardé. Sur Android 6, ce qui est noté, c'est que la vuln est particulièrement désastreuse, mais il ne me semble pas avoir lu "avant le 6, c'est bon, vous êtes safe". Ce que j'en ai conclu, c'est que ça devait être comme le reste, mais je peux me tromper.
Oui, mais ça donne une très bonne idée, qui ne doit pas être si loin de la réalité car la très grande majorité des devices embarquent le playstore. La seule exception que je connaisse c'est la Chine, et le support des versions chez les constructeurs sur le marché intérieur est assez … sommaire. Y a probablement aussi une petite part de gens qui ont un téléphone qui pourrait causer à Google mais qui ne le fait pas, car soit les Google Play Services ont été giclés ou il y a une rom custom, mais désolé, ça ne doit pas faire bezef sur le total.
[^] # Re: security update
Posté par Anonyme . Évalué à 1.
C'est pas ce que j'avais compris des commentaires précédents, tu as raison :)
Pour les stats, j'imagine que la réalité est très probablement bien pire que les 50% vu le nombre de gens (souvent les vieux) qui utilisent leur android comme un feature phone et qui ne le connectent pas ou rarement à internet, préférant consulter leurs courriels ou faire du surf Web sur un écran plus grand (hé oui la vue baisse). La RPC me semble aussi un marché énorme non répertorié (Xiaomi a son propre dépot pour sa distribution maison) et comme tu le dis les constructeurs chinois font très peu de suivi et ce dès le début de la chaine de conception, càd les différents composants que contiennent les SOC (mais les constructeurs non chinois ne sont pas beaucoup mieux, ARM elle-même ne montre pas l'exemple).
Pour moi, cette statistique ne donne pas une "très bonne idée" de l'ampleur d'exploitation de ces failles, ça donne seulement une fourchette basse d'appareils concernés.
[^] # Re: security update
Posté par Christophe . Évalué à 1.
A noter, ironie du sort, que l'élément fautif ici est wpa_supplicant, une brique libre de l'OS Android…
Ce qui veut donc dire aussi que les différentes distributions Linux réutilisant les pilotes Android (SailfishOS, Plasma Mobile, Ubuntu Touch, LuneOS, etc) peuvent corriger le problème immédiatement.
[^] # Re: security update
Posté par TuxMips . Évalué à 4.
Vu sur le bugzilla de Mageia :
les correctifs sont encore en "testing" pour la 6 mais ca ne devrait vraiment pas tarder à être publié …
# Quelques commentaires dérivés du blog de Bruce Schneier
Posté par lhardy philippe (site web personnel, Mastodon) . Évalué à 8.
Mes commentaires sont dérivés de ceux-ci : https://www.schneier.com/blog/archives/2017/10/new_krack_attac.html ,donc si vous préférez le plat frais plutot que le rechauffé, le lien est meilleur.
Selon schneier Cette attaque est brillante, car elle est évidente ( pour lui ndlr :-) ) et est restée indetectée pendant plus de dix ans.
le WPA2 est issu de l'IEEE dont les standards sont payants, et complexes, conçus derrières des portes closes pendant des meeting privés, non accessibles facilement aux chercheurs en sécurité; ce n'est pas le cas pour les standards IPSec et TLS par exemple qui viennent de l'IETF et sont disponible partout sur le net.. Il a été fait récemment des améliorations pour l'accès aux chercheurs ( programme GET mais six mois après leur utilisation publique. -je cite la citation du blog de Matthew Green- Le process complet est stupide, il coute à l'industrie des dizaines de millions de dollars, cela doit stopper -
( Il semble implicite que l'implémentation aurait certainement été meilleure avec un standard plus clair/disponible à la relecture. )
Le dernier commentaire est plus intéressant indiquant que cette attaque n'est pas bien grave pour l'utilisateur moyen car
je rajouterai ici que toute connection https suffira pour réintroduire la couche de confidentialité perdue, et donc même avec cette faille ( si l'on fait un tant soit peu attention aux certificats ) on peut continuer à accéder à sa banque par exemple.
( En gros ça n'est pas plus mauvais que les connections en portail captif ouvert fournis par les hotels par exemple. )
Il est noté que n'affectant que linux et android elle n'est pas utilisable pour mac ou windows … ( bon cet argument aura peu d'impact ici je pense :-) )
[^] # Re: Quelques commentaires dérivés du blog de Bruce Schneier
Posté par claudex . Évalué à 10.
Si, elle l'est. C'est le reset de la clef à zéro qui est spécifique à wpa_supplicant mais les autres implémentation sont susceptibles au rendu de nonce avec CBC qui permet le déchiffrement du trafic.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Quelques commentaires dérivés du blog de Bruce Schneier
Posté par gUI (Mastodon) . Évalué à 2. Dernière modification le 18 octobre 2017 à 08:18.
Oui, mais je me demande si cette 2e possibilité n'est pas plus théorique que autre chose. La première situation (clé connue à l'avance avec que des zéros) rend trivial le déchiffrement. La 2nde, beaucoup moins. Me trompé-je ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Quelques commentaires dérivés du blog de Bruce Schneier
Posté par claudex . Évalué à 5.
Il me semble que c'est quand même assez facilement attaquable, surtout que le trafic est en partie connu et identifiable (ARP, DHCP, requêtes DNS vers des noms connu (serveurs de mise à jour, détection de proxy…)…,).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.