Faille majeure dans WPA2/Wi-Fi

Pause Café
#1

Salut
Pas mal :joy:

Special parano

https://www.krackattacks.com/
_For an attacker this is easy to accomplish, because our key reinstallation attack is exceptionally devastating against Linux and Android 6.0 or higher. This is because Android and Linux can be tricked into (re)installing an all-zero encryption key (see below for more info). _
linux’s wpa_supplicant v2.6 is also vulnerable

on est mal`:joy: :scream:

apt-cache policy wpasupplicant
wpasupplicant:
  Installé : 2:2.4-1+deb9u1
  Candidat : 2:2.4-1+deb9u1
 Table de version :
 *** 2:2.4-1+deb9u1 500
        500 http://deb.debian.org/debian-security stretch/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2:2.4-1 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
        500 http://deb.debian.org/debian stretch/main amd64 Packages
     2.3-1+deb8u5 500
        500 http://deb.debian.org/debian-security jessie/updates/main amd64 Packages
     2.3-1+deb8u4 500
        500 http://deb.debian.org/debian jessie/main amd64 Packages
1 J'aime
#2

Salut,

Non, tout va bien :

For the oldstable distribution (jessie), these problems have been fixed
in version 2.3-1+deb8u5.

For the stable distribution (stretch), these problems have been fixed in
version 2:2.4-1+deb9u1.

For the testing distribution (buster), these problems have been fixed
in version 2:2.4-1.1.

For the unstable distribution (sid), these problems have been fixed in
version 2:2.4-1.1.

[SECURITY] [DSA 3999-1] wpa security update

#3

Je ne doute pas vraiment de la réactivité des logiciels libres, par contre pour tout le reste…
Je ne parierais pas qu’aucun nouveau système sera commercialisé en 2018 avec la faille non-corrigée et encore moins que les systèmes existants seront tous corrigés.

1 J'aime
#4

Puisque c’est corrigé c’est de la responsabilité de l’utilisateur de mettre à jour
Au minimum de positionner unattended-upgrades pour avoir les maj de sécurité en automatique

#5

D’après le CERT US, pour se faire une idée de la réactivité de chacun… (et du coup, de celle de zdnet.fr)

voir : https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4

#6

Enfin, il ne faut pas oublier que si nos différentes distributions Linux, *BSD vont rapidement faire leur mise-à-jour - d’ailleurs, à ce titre sous OpenBSD à jour, c’est patché en partie depuis quelques mois - ce ne va pas du tout ou très peu le cas, sur les android !!!

Sachant que c’est la majorité des périphériques “linuxiens”… le tableau ressemblera plus au “Cri” !

N’est pas à ce jour.
On sait assurément, que du côté OpenBSD, le patch 27 sur 6.1 corrige cette faille ; 6.2 en hérite !
(enfin pas pleinement ; il y aurait un autre correctif en attente de diffusion)

#7

Les infos en français de l’agence gouvernementale

http://www.cert.ssi.gouv.fr/alerte/CERTFR-2017-ALE-014/

#8

L’embargo n’a pas été respecté et c’est plutôt un problème… pour les autres systèmes pendant lesdits mois.

#9

Que cette faille soit corrigée pour les différents SE, c’est déjà bien,
mais ce qu’il faudrait maintenant, c’est qu’une mise à jour apportant cette correction
soit appliquée sur ma box et celles auxquelles je me connecterai quand je sortirai de chez moi.

Ceci dit, quand je ne suis pas chez moi, j’utilise l’EAP-SIM de mon smartphone pour me connecter au web avec mon PC portable

#10

Apparemment, c’est faux !

Je me permets de citer ce que @Mimoza a écrit sur notre forum obsd4a :

En gros il y a eu un premier délai d’attente, qui a été respecté. Mais une fois que les chercheurs ont communiqués la faille au CERT (donc les agences gouvernementales entre autres) un deuxième délai a été demandé, ce que Théo n’a pas voulu et après discussions est arrivé à l’accord de patcher l’OS silencieusement, donc sans mentionner que le patch concernait cette faille précisément.

#12

OK.

To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.

https://www.krackattacks.com/#faq

#13

Alors, jcsm33, tu reprends, stp, le lien que j’ai fourni et tu te rendras compte que c’est clairement une réponse fournie à ce que tu soulignes !

Et, comme, pour une fois je n’ai vraiment pas envie “d’être gentil” - mais rien de spécifique à ton égard, bref à ne pas prendre pour toi, je réécris ici, ce que j’ai écris sur notre forum obsd4a.net :

Après tout cela - càd le boucan fait autour - me fait doucement sourire.

Mis-à-part OpenBSD, ils sont tous entrain de se bouger le derrière pour patcher ce qui peut l’être, certains comme Apple (MacOS) ou Google (Android) étant à la traîne très clairement, c’est même le très décrié Microsoft qui change la donne… quant à nos très chères distributions GNU/Linux - wpa_supplicant est màj -, sur ce coup, elles ne font pas mieux ; mais, ils le font tous une fois que c’est rendu publique, et donc que le grand public s’émeuve !
"Oh, mon dieu… on n’est maintenant obligé de faire quelque chose !"
Ils ne pouvaient pas le faire avant, toute cette bande d’hypocrites plus ou moins mercantiles ! ?
Les délais de réserve sont justement fait pour que, du fait d’être informé secrètement, ils fassent tous le nécessaire… mais non !

Sincèrement, que TdR, malgré son fichu caractère impose par le biais de celui-ci que son SE soit mis-à-jour le plus rapidement possible, voire secrètement parce que les autres ne veulent pas jouer le jeu, et veille à ce qu’il n’y ait pas de repousse du 2d délai… me semble largement préférable.

Alors, reprocher à TdR d’avoir fait son “job”, considérer la sécurité de son SE comme étant d’une importance primordiale, et lui imposer un moratoire… pour se venger. Je préfère taire ce que j’en pense ! Sad

Voilà, c’était mes deux cents…

1 J'aime
#14

Je voulais simplement souligner que le chemin choisi - on informera OpenBSD que vers la fin de l’embargo - est très étonnant.

#15

Oui, nous sommes plusieurs à être étonné…

C’est comme s’ils voulaient punir TdR d’avoir, lui fait correctement son “job” vis-à-vis de son SE, et lui reprocher de l’avoir sans attendre que les autres veuillent bien se bouger ; et pour se bouger, il faut que l’annonce soit publique.
Alors, qu’il a apparemment respecté le délai initial, donc le processus, et qu’il a clairement avertit qu’il n’attendrait pas la publication officielle du deuxième délai.

D’autant que hier, on apprend que Microsoft a fait de même aussi… en silence.

Ceci est un jugement personnel : “Bande d’hypocrites !” que je leurs crierait bien à la figure ! :stuck_out_tongue:

#16

Ultime interrogation : à quoi sert l’embargo ?

#17

De ce qui est compréhensible : empêcher que TdR corrige avant les autres !
parce qu’il aura en retard les informations… euhhh, ils vont gérer ça comment ?!

#18

Dans les explications, ce qui est reproché à Openbsd ce n’est pas tant d’avoir corrigé mais le fait que la correction dévoilait forcement la faille à tout le monde , et donc finalement ainsi risquait de provoquer une exploitation de la faille, alors que la règle est apparemment que chaque système développe une réponse pendant une phase de “silence radio” et que les corrections puissent être plus ou moins prêtes en même temps.
Puisque Opensbsd est puni, dans l’avenir il ne sera informé des failles que tardivement afin de ne pas les mettre sur la place publique

#19

C’est ni plus ni moins stupide !

Et les corrections bien sûr étaient prêtes en temps et en heures…

Tsss

#20

Côté box ça a l’air d’être ok

#21

Un point de vue intéressant

1 J'aime