Journal WPA2 est bronsonisé

Posté par . Licence CC by-sa
36
16
oct.
2017

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 . Évalué à 10 (+18/-2).

    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 . Évalué à 3 (+3/-2).

      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 . Évalué à 10 (+11/-1).

        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 . Évalué à 7 (+7/-2).

          Les deux utilisent wpa_supplicant qui est en effet le pire sur le sujet mais bon si on lit en details:

          In particular this means that attacking macOS and OpenBSD is significantly easier than discussed in the paper.

          Et encore:

          we discovered ourselves that Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys, and others, are all affected by some variant of the attacks.

          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:

          OpenBSD was notified of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: “In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging”. Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.

          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 . Évalué à 5 (+6/-2).

            Ici OpenBSD n'y est pour rien !

            As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision

            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 (page perso) . Évalué à 10 (+9/-1).

              Ici OpenBSD n'y est pour rien !
              […]
              C'est lui qui a autorisé OpenBSD à faire la correction en avance.

              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 (page perso) . Évalué à 8 (+6/-0).

                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 . Évalué à 7 (+7/-2). Dernière modification le 16/10/17 à 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 (page perso) . Évalué à 4 (+2/-0).

                    En même temps 1 mois c'est déjà extremement long pour ce type de failles.

                    Ç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 . Évalué à 8 (+8/-2).

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

                      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 (page perso) . Évalué à 10 (+14/-1).

                    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.

                    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 . Évalué à 1 (+2/-3). Dernière modification le 16/10/17 à 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 (page perso) . Évalué à 7 (+4/-0).

                        T'es pas obligé de tout faire planter. Tu peux aussi informer tes utilisateurs et les inciter à désactiver le wifi en attendant.

                        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.

                        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.

                        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 . Évalué à -1 (+0/-3).

                          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 . Évalué à 6 (+7/-3).

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

                      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 (page perso) . Évalué à 3 (+4/-3).

                    En même temps 1 mois c'est déjà extremement long pour ce type de failles.

                    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.

                    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.

                    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 (page perso) . Évalué à 7 (+5/-0).

                      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.

                      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 . Évalué à 2 (+1/-1).

                        « 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»

                        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 (page perso) . Évalué à 4 (+2/-0).

                      SSL everywhere!

                      SSL c'est dépassé. Il faut utiliser TLS maintenant.

                    • [^] # Re: commentaire link

                      Posté par (page perso) . Évalué à 2 (+1/-1).

                      IMAPS, SMTPS

                      Y a vraiment des gens qui n’utilisent pas STARTTLS ?

          • [^] # Re: commentaire link

            Posté par . Évalué à 4 (+3/-1).

            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 (page perso) . Évalué à 10 (+8/-0).

              pourquoi wpa_supplicant est-il le pire?

              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 (page perso) . Évalué à 9 (+8/-1).

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

                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 (page perso) . Évalué à 4 (+2/-1).

                  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 . Évalué à 1 (+5/-5).

                    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 (page perso) . Évalué à 8 (+5/-0).

                      je croyais que le code libre est trop bien audité parce que libre.

                      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 . Évalué à -8 (+5/-15).

                        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 . Évalué à 10 (+15/-0).

                          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 . Évalué à 8 (+5/-0). Dernière modification le 17/10/17 à 16:26.

                          Et ouais, le libre c’est génial parce que c’est quelqu’un d’autre qui fait n’importe qui ayant les compétences peut faire la vérification (ou pas).

                          Le proprio, ça pue, parce que c’est quelqu’un d’autre l’éditeur qui fait la vérification (ou pas).

                          Donc « kifkif », même en pratique, j’émets quelque réserve.

                          les deux ont des failles béantes publiées et non decouverte/corrigées pendant des années

                          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 (page perso) . Évalué à 4 (+4/-2).

                    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 (page perso) . Évalué à 4 (+1/-0).

                      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 (page perso) . Évalué à 2 (+1/-1).

                        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 . Évalué à 4 (+3/-1).

                          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 . Évalué à 10 (+10/-1).

                  « 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 . Évalué à 4 (+3/-1).

              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 . Évalué à -10 (+2/-27). Dernière modification le 16/10/17 à 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 . Évalué à 10 (+16/-0).

      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 . Évalué à 3 (+2/-1).

      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 . Évalué à 7 (+10/-5).

        Parceque j'ai comme un doute que pour 99,99999999% des utilisateurs de systeme d'exploitations soit capable/interesse de le faire.

        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 (page perso) . Évalué à 3 (+2/-0).

        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 . Évalué à 4 (+3/-1).

      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 (page perso) . Évalué à 6 (+4/-0).

        Ç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 . Évalué à 1 (+1/-0).

    On dirait que la faille est déjà patchée:

    wpa (2.4-0ubuntu6.2) xenial-security; urgency=medium

    • SECURITY UPDATE: Multiple issues in WPA protocol
      • debian/patches/2017-1/*.patch: Add patches from Debian stretch
      • CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13086, CVE-2017-13087, CVE-2017-13088
    • SECURITY UPDATE: Denial of service issues
      • debian/patches/2016-1/*.patch: Add patches from Debian stretch
      • CVE-2016-4476
      • CVE-2016-4477
    • This package does not contain the changes from 2.4-0ubuntu6.1 in xenial-proposed.

    Ça n'a pas trainé

    • [^] # Re: security update

      Posté par (page perso) . Évalué à 6 (+3/-0).

      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 . Évalué à 8 (+7/-0).

      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 . Évalué à 2 (+1/-1). Dernière modification le 17/10/17 à 13:29.

        c'est chez les nombreux appareils sur Android 6. Ça risque même de trainer indéfiniment sur certains modèles […]

        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 . Évalué à 1 (+0/-0). Dernière modification le 17/10/17 à 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 . Évalué à 4 (+2/-0).

            Bien entendu mais ce bug est censé concerner Android 6 et supérieur donc j'en parle même pas.

            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.

            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.

            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 . Évalué à 1 (+0/-0).

              d'autant que wpa_supplicant était déjà dedans en 4.0.4.

              C'est pas ce que j'avais compris des commentaires précédents, tu as raison :)

              mais désolé, ça ne doit pas faire bezef sur le total.

              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 . Évalué à 1 (+1/-1).

            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.

            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 . Évalué à 4 (+3/-0).

      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 (page perso) . Évalué à 8 (+7/-0).

    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

      • Il a déjà un mot de passe wifi bidon, donc était déjà vulnérable à l'écoute de son traffic
      • Elle ne peut de toutes façon avoir lieu qu'à portée wifi de l'équipement.
      • Le réseau entier n'est pas compromis ( seulrs les communications entre le point d'accès et l'équipement wifi le sont )
      • il est critique principalement pour les entreprises qui reposent sur WPA2 pour assurer leur confidentialité.

    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 (page perso) . Évalué à 10 (+10/-0).

      Il est noté que n'affectant que linux et android elle n'est pas utilisable pour mac ou windows

      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 . Évalué à 2 (+1/-1). Dernière modification le 18/10/17 à 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 ?

        • [^] # Re: Quelques commentaires dérivés du blog de Bruce Schneier

          Posté par (page perso) . Évalué à 5 (+2/-0).

          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

Envoyer un commentaire

Suivre le flux des commentaires

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