[tialaramex]

The attacker doesn't need to be connected to the victim's network, only to the same hardware, the hardware's loss of isolation is the unexpected problem.

Their University example is pertinent. The victim is an Eduroam user, and the attacker never has any Eduroam credentials, but the same WiFi hardware is serving both eduroam and the local guest provision which will be pretty bare bones, so the attacker uses the means described to start getting packets meant for that Eduroam user.

If you only have a single appropriately authenticated WiFi network then the loss of isolation doesn't matter, in the same way that a Sandbox escape in your web browser doesn't matter if you only visit a single trusted web site...

[dijit]

I should reinforce this point by saying that it's the default position for "guest" networks to be using the same hardware as "secure" office wifi and such.

[TeMPOraL]

I'd further reinforce this by pointing out that this is what the specific term, guest network, means - it's the common name used by router manufacturers to describe an optional feature of serving secondary network from the same hardware, intended for the specific, common use case of serving transient and/or less trusted users.

This is in contrast to more genetic, descriptive terms like "additional network", "separate network for guests", etc.

[benlivengood]

Yeah, that commercial-grade hardware didn't actually isolate at the PHY-MAC layer is a bit surprising. How would they have working VLANs at the AP?

[eqvinox]

802.11 is kinda poorly designed in this regard, but they do isolate to some degree. I need to read the paper, some claims here have a very strong "misunderstood or wrong or specific vendor problem" smell.

[thenthenthen]

Fun story, back in uni, if you would spin up a webserver ($ python -m http.server 8000 for example) one could access it from other campuses. We never tried it across countries, but it might (have) worked