221–230 of 424 posts
Earlier quoted context omitted.
Currently the only mitigation is to constrain your browsing to properly configured https (SSL) web sites.
Too bad DNS doesn't fall under properly protected against local attacks.
"This is achieved by manipulating and replaying cryptographic handshake messages." so that means that the mac address has been spoofed to make the AP think that he is always talking to the same mac address. If I'm plugged into the router directly then i should be good because it eliminates the wifi handshake. So even though other devices on the wifi network could be affected, the node that is plugged in is safe again…
Eh, yes, if you're plugged in you're good because it eliminates Wifi, period.
For that one client, anyway.
I'm not sure I understand the concern with breaking WiFi. Okay, so you're vulnerable to snooping and injection by people in the same coffee shop or your neighborhood. But you're already vulnerable to that from anybody on the Internet between you and the site. HTTPS solves both of these. Am I missing something?
However, homes, coffee shops, airports, etc -- those are places where someone could execute this attack successfully.
You're right that any transit router could intercept your connection and do these things but in practice those routers are "reasonably" well secured.
The research talks a lot about how it somewhat depends on the implementation of the wireless client, but only in regards to Linux and OpenBSD, anybody know what the status on the Windows implementation is?
Seconding this. I wonder if it is something fixable at the OS level, or if individual WiFi drivers need to be updated too.
Would love to see someone throw together a list of OS', Routers, and other WiFi stuff that is known to be patched/unpatched/unknown.
As an Android user is there any mitigation for this other than ditching my handset and switching to an iPhone or waiting (hopelessly) for a patch from my vendor. This really does highlight the absolute disaster zone that the Android handset market has become as far as updates are concerned. I'm sure the Pixels will get a fix relatively quickly but almost every other Android user is going to be left in security limbo.
Earlier quoted context omitted.
Too bad DNS doesn't fall under properly protected against local attacks.
Fortunately, SSL/TLS (with HSTS) does not depend on your local DNS resolver being secure.
> 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 discl…
Seems rather prisoner-dilemma-ish[1]. Up until now, there were no indications that this was being exploited publicly. After a flaw like this gets known (whether through a coordinated disclosure or through OpenBSD's early patch) you can be assured people will be exploiting this. Do you both stay silent and take the minor risk of your users being vulnerable for a short time longer whilst patching and disclosure is bein…
As an Android user is there any mitigation for this other than ditching my handset and switching to an iPhone or waiting (hopelessly) for a patch from my vendor. This really does highlight the absolute disaster zone that the Android handset market has become as far as updates are concerned. I'm sure the Pixels will get a fix relatively quickly but almost every other Android user is going to be left in security limbo.
or waiting (hopelessly) for a patch from my vendor If this is an actual in the wild exploitable issue, there will be patches very quickly for handsets in the support period, as quickly as there is for iOS. This has been the case repeatedly before as well. What a weird post in general. Maybe wait to complain about this a month down the line or so? Instead it's just effectively noisy rhetoric.