[TekMol]

    vulnerable to remote code execution from
    systems on the same network segment

Isn't almost every laptop these days autoconnecting to known network names like "Starbucks" etc, because the user used it once in the past?

That would mean that every FreeBSD laptop in proximity of an attacker is vulnerable, right? Since the attacker could just create a hotspot with the SSID "Starbucks" on their laptop and the victim's laptop will connect to it automatically.

[francasso]

If you run FreeBSD on your laptop you don't auto connect to public WiFi.

Joking, but not that much :)

[badgersnake]

Your wifi chip probably isn’t supported tbh.

[keyle]

This is the real joke.

[BSDobelix]

FreeBSD 15 had a massive improvement with WiFi, however if you let your Computer auto-connect to a "unknown" Network...well that's not good.

[TekMol]

My question was about known networks.

As far as I know, access points only identify via their SSID. Which is a string like "Starbucks". So there is no way to tell if it is the real Starbucks WiFi or a hotspot some dude started on their laptop.

[BSDobelix]

>So there is no way to tell if it is the real Starbucks WiFi or a hotspot some dude started on their laptop.

Aka "unknown" or "public" Network....don't do that.

[integralid]

There is nothing wrong with using public networks. It's not 2010 anymore. Your operating system is expected to be fully secure[1] even when malicious actors are present in your local network.

[1] except availability, we still can't get it right in setups used by regular people.

[breakingcups]

Unless you run FreeBSD, apparently

[TekMol]

You don't use public networks?

And when you connect to a non-public WiFi for the first time - how do you make sure it is the WiFi you think it is and not some dude who spun up a hotspot on their laptop?

[somat]

Why does it matter? I mean I guess it did in this case but that is considered a top priority bug and quickly fixed.

I guess my point is the way the internet works is that your traffic goes through a number of unknown and possibly hostile actors on it's way to the final destination. Having a hostile actor presenting a spoofed wifi access point should not affect your security stance in any way. Either the connection works and you have the access you wanted or it does not. If you used secure protocols they are just as secure and if you used insecure protocols they are just as insecure.

Now having said that I will contradict myself, we are used to having our first hop be a high security trusted domain and tend to be a little sloppy there even when it is not. but still in general it does not matter. A secure connection is still a secure connection.

[evandrofisico]

WPA2-entreprise and WPA3 both have certificate chains checking exactly to avoid such attacks

[tialaramex]

Hmm. Are you sure that your stack wouldn't accept these discovery packets until after you've successfully authenticated (which is what those chains are for) ?

Take eduroam, which is presumably the world's largest federated WiFi network. A random 20 year old studying Geology at Uni in Sydney, Australia will have eduroam configured on their devices, because duh, that's how WiFi works. But, that also works in Cambridge, England, or Paris, France or New York, USA or basically anywhere their peers would be because common sense - why not have a single network?

But this means their device actively tries to connect to anything named "eduroam". Yes it is expecting to eventually connect to Sydney to authenticate, but meanwhile how sure are you that it ignores everything it gets from the network even these low-level discovery packets?

[Fhch6HQ]

I may be missing something, but it is almost a guarantee that you would not receive a RA in this scenario? eduroam is using WPA2/WPA3 enterprise, so my understanding is that until you authenticate to the network you do not have L2 network access.

Additionally, eduroam uses certificate auth baked into the provisioning profile to ensure you are authenticating using your organizations IdP. (There are some interesting caveats to this statement that they discuss in https://datatracker.ietf.org/doc/html/rfc7593#section-7.1.1 and the mitigation is the usage of Private CAs for cert signing).

[hhh]

dozens of people will be affected