Hotels and airlines have been making hotel and airline wifi networks difficult. iOS 14 has been out for years, they could’ve adjusted their networks by now.
I mean, yes, I suppose the title is technically correct. But phrased another way: there was a security vulnerability which someone found and reported to Apple, and Apple fixed it. Isn't that how things are supposed to work? Unless you expect everyone to write perfect software on the first try.
If your company is prioritizing security and privacy, no, this is not how it's supposed to work.
This shows a failure of the process. By design/default, this MAC address should not be available to system or user processes in IOS. In general, even the randomized MAC address should not be available. The fact that it was available to the mDNS process indicates that there was no security/privacy review of its existing access, no technical measure implemented to break that access until a review or exception was put into place, and no test plan that validated that the MAC address is never sent on the WIFI radio.
HN auto-incorrects all-caps acronyms in titles when submitting a link. It is a very annoying "feature" with questionable purpose because it's nearly always wrong.
I don’t wish to trivialize this CVE, CVE-2023-42846, but it is fascinating that it received a High severity and a base score of 7.5.
Devices reporting their MAC is standard practice. All these apple devices did it as standard practice as well before iOS 14. Yet, they added the buggy feature in iOS 14, and get a high severity CVE in return. Just fascinating. How does this work? Does it imply other devices that report their true MAC address are deserving of a high CVE as well?
Just strange to use HTTP for comparison when the actual problem works just fine.
If I'm connecting to WiFi normally, and expecting that I can be tracked, there isn't a vulnerability.
If I'm connecting to WiFi using this privacy feature, and expecting NOT to be trackable, yet someone is still able to track me, there is a serious vulnerability!
I would argue you’re almost right, the two considerations are intent (if you say something is true and it is not true, that is a vulnerability) and real world use (if the site accepts usernames and passwords, and is unencrypted, and there is some impact to a breach or credential theft, there is a vulnerability).
It implies that other devices that are not supposed to report their MAC, but do, deserve a high CVE as well.
This has to do with a bug seriously compromising a feature. It does not reflect the overall security rating of the entire device. If I have a one-way data diode sending telemetry from the flight controller to a passenger's entertainment console, it works as intended - which is why they put in a layer1 one-way diode. When you have a feature, you use that feature for a scenario where it is useful.
If the flight controller data diode has a second fiber and allows it to be hacked from a passenger seat entertainment center, that is a high severity. It does not mean every network switch has a high severity security issue, because we don't put those into flight controllers that hook up to entertainment centers.
Let's do a car example. If I rent a Uhaul to move my piano, and it splits in half from the weight, this is a serious malfunction. It does not mean the mini-coop croaking from a piano loaded on it's hood is also a serious malfunction.
Let's do a food example. If I put an empty metal frying pan on a stove and it bursts my house into flames, this is a serious problem with the frying pan. If I put it in the microwave and it does that, that's not a problem with the frying pan.
This question and many more can be applied on using CVSSv3. So a pentester doesn't have to use CVE scores as holy bible in their report. A risk assessment can be worked upon by those who are going to consider the recommendations in the report.
I don't understand this. By that logic you could go from HTTP to a new but buggy and flawed HTTPS (when that was in its infancy) and rather than that being considered a vulnerability, you could say "Well, everyone else is just using HTTP so they deserve a CVE too..."
No, because the advertised additional security may cause people to do things that they would not otherwise have done had they not falsely believed the security claims on the newer protocol.
Security people always use this crazy risk matrix where if it’s easy to reproduce and affects a lot of people, it becomes high severity even if there is essentially no real world risk. I guess it makes them look better when they can show all the “high” severity issues they found.
> In fairness to Apple, the feature wasn't useless, because it did prevent passive sniffing by devices such as the above-referended CreepyDOL.
Wasn't passive sniffing the primary issue being defended against? So it sounds like it actually did the most important job.
I am really curious how it managed to put the real MAC into this particular mDNS packet though, when presumably all other network traffic uses the randomized per-network MAC.
A few years ago I was trying out mdk3's FakeAP feature.
It had the ability to create thousands of fake APs and crash some devices.
I was playing around with it on a MacBook that didn't have OS X for a few months, as I completely erased it and installed a Linux distro on it.
I started toying around with the FakeAP, pretty impressed by the huge list of networks with random names that were now appearing and dissapearing.
But then, I was struck with horror. Something must've happened inside the hardware, because the network names were not random anymore. It was still advertising new networks like crazy, but they had the SSIDs of the networks I had connected to in the past. From the work network, to all the coffee places I went to, friend networks, etc.
I have my beef with Apple, and the fact that they store the networks you connect to on a chip is just a part of it. There's no good reason (for the users) to do this, and it shows a complete disregard for privacy.
Apple has compromised user privacy in the past (China) to avoid govt crackdown. I wouldn't be surprised if high-level agencies routinely mandate specific "functionality".
macOS too, at least previous version (not sure if still). I know this from installing a Pineapple (which has the same feature [1]) and seeing my SSID from home in it while the machine was at that point connected to wired, and not at home at all. This was approx 4 years ago, a few months before Covid pandemic.
Either way, don't have Auto Join on. And, wired as much as possible. I guess in some point in future we only end up using mmWave and no more 2.4 GHz.
[1] Nowadays you can do this too with a Flipper Zero e.g. with wlan dev board.
Did you? Sounds like you're using MacOS. GP said he wiped MacOS and installed Linux, but sees SSIDs which persist from MacOS. Like those SSIDs got saved in hardware.
I am convinced there is definitely a Reality Distortion Field but that it works both ways.
Some Apple Intel Macbooks came with an Arm T2 chip that controls security-related functions, e.g. disk encryption. With Apple Silicon, that capability is part of the M1/M2 SoC.
If network SSID history is/was stored on the T2 chip, then it could likely be removed using MacOS settings before installing another operating system.
This really is a feature on Macs. It works for Bluetooth too, apparently to allow network/keyboard/mouse functionality to work in recovery mode and to unlock an encrypted disk.
It's still stored in NVRAM, which the OS (or EFI firmware) has to consciously parse and then give to whatever process manages network connections. Nothing is stored in the wireless chip itself - those are generally stateless.
This likely had nothing to do with your Mac specifically. All wireless devices basically broadcast a statement out for anything to hear which goes like “Hey, here’s a full list of every SSID I’ve ever connected to, any of them available right now?” It’s very likely the program you were using caught one of those broadcasts from another one of your devices.
More devices still do than you might think. Had someone needing access into an Android phone recently. Wireless attacks proved easier than wired for that one. It broadcasted its list and from there was just a matter of spinning up SSID’s until I hit one that didn’t have a PW.
I have no idea what apple is doing but I will note that "fullmac" style radios have most of their operation internal to the device. The downside is now you have some strange insecure os running on the radio. The upside, the driver is simpler, and the system more power efficient. that is, you don't need an 802.11 stack.
This is why you use ath9k hardware, folks. You get the source code that implements the MAC and management layers so you can see exactly what they are doing.
Sounds useful in general, but in this case the problem wasn’t that low-level. It was just some daemon that decided to include a copy of the MAC address in the body of a UDP packet it was sending.
When you have the baseband source code, you can remove the part that allows the host to read the EEPROM MAC address. Replace it with a random number generated on each request.
Then you don't have to care what some daemon does with that random number.
Instead of worrying about handling these unique identifiers, solve the problem at its source: get rid of the unique identifier. Much more reliable solution. The baseband firmware is the lowest level of software at which this fix can be made (everything below it is hardware). If you fix it at some higher level you can never be sure the fix hasn't been circumvented.
I don't know if all Android version do this by default, the one on my phone does: Whenever it connects to an AP, it generates a new random Fake-MAC. So, it's not a per-SSID permanent MAC, but a new one on each reconnect.
Now, at Bahrein Airport the WiFi coverage is somewhat spotty. Due to this you have lots of devices reconnecting. And each time they register with a new MAC.
The DHCP server behind their WiFi has a least time of 14 days. And even with them having chosen a /16 IP range for their DHCP, at an airport you can already imagine that those limits are not clever.
And even worse: The system is self-DDoS'ing. This is because every time a phone connects, and the DHCP server has run out of IPs, after a couple of seconds the phone will disconnect, and then try to reconnect - with ANOTHER random MAC address.
The solution I used myself (and showed to a couple of other people in the lounge was) was disabling the privacy feature. This way your MAC would stay the same. You then would keep hammering the AP until one of the thousands of leases had timed out and a IP was available again. You'd then get this IP, and due to your MAC staying constant having reconnects to it (for example because you went to the toilet) also aren't a problem.
So, let this be a lesson to those administrating large public WiFis: Now that devices use random MAC addresses, consider to make your DHCP pool larger, and the lease time much shorter. Unless you are Tom Hanks, you would not typically stay 14 days in an airport terminal. :)
Similar at the Flamingo Hotel in Vegas. Our room came with 2 free Wi-Fi connections. (I'm sure it's entirely coincidental that there was zero cell signal in our room.) Extra connections were around $15 per day.
Their IT defines a MAC address as a connection. If your device uses random MACs, plan on disabling that in advance or spending half an hour on the phone with their tech support to get your device back online.
I bought a gl.inet travel router a while back and it kicks ass. Being based on OpenWRT it has a ton of features, but also just works when I need it. I can even do wire guard on the router back to my home network, which I've found helps defeat hotels that block you if they detect multiple devices sharing an IP.
> I don't know if all Android version do this by default, the one on my phone does: Whenever it connects to an AP, it generates a new random Fake-MAC. So, it's not a per-SSID permanent MAC, but a new one on each reconnect.
I do not even have this as an option except in the developer settings. I get either a per-SSID permanent MAC (the default) or the device's actual hardware MAC.
Are you sure? Not sure if there is a global setting, but if you press the gear icon next to a WiFi connection entry, there is a "privacy" option which in my case by default says "User random MAC-Address (default). I have that option even if developer options are turned off.
The random MAC generated by my Pixel (still holding onto Android 13) are per SSID, not connection. So maybe the behavior you observed is manufacturer-specific.
Yes, in the per-connection settings there is a "privacy" option named "Use randomized MAC (default)".
Enabling that setting (which, as noted, is enabled by default) gives you a permanent per-SSID MAC address that is used for that connection. It's listed under "Network details" on the same screen, as the "Randomized MAC address". For my local home network, my "randomized", in the sense of being more fixed and eternal than the stars, address is 76:78:c9:94:2a:94, and I cannot change it, other than by changing the setting. The only other MAC-address-related option on this screen is "Use device MAC". If I switch the randomized MAC off, and then switch it back on, I still have exactly the same "random" address that I am required to have for all of time.
However, if you enable the developer options, you can find the option for "Wi-Fi non-persistent MAC randomization". It says "When this mode is enabled, this device's MAC address may change each time it connects to a network that has MAC randomization enabled."
(This is all on stock Android, on a Pixel phone.)
You shouldn't confuse the name of a setting with the behavior that setting controls. The name of the setting is lying to you.
Sqlite's "autoincrement" column modifier is another good example of this phenomenon. It's named "autoincrement", but as the documentation for the modifier notes, you will get autoincrement functionality on a primary key column regardless of whether that modifier is set, and the behavior controlled by the setting is something entirely different. ("Autoincrement" means that values in that column, once they have ever existed, may never exist in another row, even if the row in which they originally existed has been dropped. You may notice that this has nothing to do with the meaning of the word "autoincrement". Other people have noticed that too.)
> So, let this be a lesson to those administrating large public WiFis
Or adopt IPv6 with NAT64! All mobile devices support this now since many large mobile networks are adopting it, Apple requires apps support it to be approved for the App Store, etc.
"On Wednesday, Apple released iOS 17.1. Among the various fixes was a patch for a vulnerability, tracked as CVE-2023-42846, which prevented the privacy feature from working. Tommy Mysk, one of the two security researchers Apple credited with discovering and reporting the vulnerability (Talal Haj Bakry was the other), told Ars that he tested all recent iOS releases and found the flaw dates back to version 14, released in September 2020."
That’s a true blunder on Apple’s part. Maybe they should spend less on the marketing department
and hire quality engineers when pumping out these privacy oriented features.
Makes you wonder if there’s anything else that might be missed.
70 comments
[ 4.5 ms ] story [ 114 ms ] thread"please use the original title, unless it is misleading or linkbait; don't editorialize." https://news.ycombinator.com/newsguidelines.html
Also, "Macs" in the submission title makes it look like Apple Macintosh rather than Media Access Control address.
but point taken, will edit
I mean, yes, I suppose the title is technically correct. But phrased another way: there was a security vulnerability which someone found and reported to Apple, and Apple fixed it. Isn't that how things are supposed to work? Unless you expect everyone to write perfect software on the first try.
If your company is prioritizing security and privacy, no, this is not how it's supposed to work.
This shows a failure of the process. By design/default, this MAC address should not be available to system or user processes in IOS. In general, even the randomized MAC address should not be available. The fact that it was available to the mDNS process indicates that there was no security/privacy review of its existing access, no technical measure implemented to break that access until a review or exception was put into place, and no test plan that validated that the MAC address is never sent on the WIFI radio.
Devices reporting their MAC is standard practice. All these apple devices did it as standard practice as well before iOS 14. Yet, they added the buggy feature in iOS 14, and get a high severity CVE in return. Just fascinating. How does this work? Does it imply other devices that report their true MAC address are deserving of a high CVE as well?
If I'm using HTTP, and my traffic is unencrypted, there isn't a vulnerability.
If I'm using HTTPS, and my traffic is unencrypted or can be decrypted, there's a serious vulnerability!
If I'm connecting to WiFi normally, and expecting that I can be tracked, there isn't a vulnerability.
If I'm connecting to WiFi using this privacy feature, and expecting NOT to be trackable, yet someone is still able to track me, there is a serious vulnerability!
The HTTP comparison helped me understand the issue.
This has to do with a bug seriously compromising a feature. It does not reflect the overall security rating of the entire device. If I have a one-way data diode sending telemetry from the flight controller to a passenger's entertainment console, it works as intended - which is why they put in a layer1 one-way diode. When you have a feature, you use that feature for a scenario where it is useful.
If the flight controller data diode has a second fiber and allows it to be hacked from a passenger seat entertainment center, that is a high severity. It does not mean every network switch has a high severity security issue, because we don't put those into flight controllers that hook up to entertainment centers.
Let's do a car example. If I rent a Uhaul to move my piano, and it splits in half from the weight, this is a serious malfunction. It does not mean the mini-coop croaking from a piano loaded on it's hood is also a serious malfunction.
Let's do a food example. If I put an empty metal frying pan on a stove and it bursts my house into flames, this is a serious problem with the frying pan. If I put it in the microwave and it does that, that's not a problem with the frying pan.
You can apply this anywhere:
FDE being broken.
Zero days being used on journalists.
Security theater post 9/11.
Your 4 y.o. choking on a toy deemed unsafe for age 0-3.
Wasn't passive sniffing the primary issue being defended against? So it sounds like it actually did the most important job.
I am really curious how it managed to put the real MAC into this particular mDNS packet though, when presumably all other network traffic uses the randomized per-network MAC.
I started toying around with the FakeAP, pretty impressed by the huge list of networks with random names that were now appearing and dissapearing.
But then, I was struck with horror. Something must've happened inside the hardware, because the network names were not random anymore. It was still advertising new networks like crazy, but they had the SSIDs of the networks I had connected to in the past. From the work network, to all the coffee places I went to, friend networks, etc.
I have my beef with Apple, and the fact that they store the networks you connect to on a chip is just a part of it. There's no good reason (for the users) to do this, and it shows a complete disregard for privacy.
macOS too, at least previous version (not sure if still). I know this from installing a Pineapple (which has the same feature [1]) and seeing my SSID from home in it while the machine was at that point connected to wired, and not at home at all. This was approx 4 years ago, a few months before Covid pandemic.
Either way, don't have Auto Join on. And, wired as much as possible. I guess in some point in future we only end up using mmWave and no more 2.4 GHz.
[1] Nowadays you can do this too with a Flipper Zero e.g. with wlan dev board.
Did you? Sounds like you're using MacOS. GP said he wiped MacOS and installed Linux, but sees SSIDs which persist from MacOS. Like those SSIDs got saved in hardware.
I am convinced there is definitely a Reality Distortion Field but that it works both ways.
That is the first I've ever heard of such a thing, and it sounds implausible.
If network SSID history is/was stored on the T2 chip, then it could likely be removed using MacOS settings before installing another operating system.
https://blog.quarkslab.com/reverse-engineering-broadcom-wire...
Then you don't have to care what some daemon does with that random number.
Instead of worrying about handling these unique identifiers, solve the problem at its source: get rid of the unique identifier. Much more reliable solution. The baseband firmware is the lowest level of software at which this fix can be made (everything below it is hardware). If you fix it at some higher level you can never be sure the fix hasn't been circumvented.
I don't know if all Android version do this by default, the one on my phone does: Whenever it connects to an AP, it generates a new random Fake-MAC. So, it's not a per-SSID permanent MAC, but a new one on each reconnect.
Now, at Bahrein Airport the WiFi coverage is somewhat spotty. Due to this you have lots of devices reconnecting. And each time they register with a new MAC.
The DHCP server behind their WiFi has a least time of 14 days. And even with them having chosen a /16 IP range for their DHCP, at an airport you can already imagine that those limits are not clever.
And even worse: The system is self-DDoS'ing. This is because every time a phone connects, and the DHCP server has run out of IPs, after a couple of seconds the phone will disconnect, and then try to reconnect - with ANOTHER random MAC address.
The solution I used myself (and showed to a couple of other people in the lounge was) was disabling the privacy feature. This way your MAC would stay the same. You then would keep hammering the AP until one of the thousands of leases had timed out and a IP was available again. You'd then get this IP, and due to your MAC staying constant having reconnects to it (for example because you went to the toilet) also aren't a problem.
So, let this be a lesson to those administrating large public WiFis: Now that devices use random MAC addresses, consider to make your DHCP pool larger, and the lease time much shorter. Unless you are Tom Hanks, you would not typically stay 14 days in an airport terminal. :)
Their IT defines a MAC address as a connection. If your device uses random MACs, plan on disabling that in advance or spending half an hour on the phone with their tech support to get your device back online.
Reminder to self: bring my own AP next time.
I do not even have this as an option except in the developer settings. I get either a per-SSID permanent MAC (the default) or the device's actual hardware MAC.
Enabling that setting (which, as noted, is enabled by default) gives you a permanent per-SSID MAC address that is used for that connection. It's listed under "Network details" on the same screen, as the "Randomized MAC address". For my local home network, my "randomized", in the sense of being more fixed and eternal than the stars, address is 76:78:c9:94:2a:94, and I cannot change it, other than by changing the setting. The only other MAC-address-related option on this screen is "Use device MAC". If I switch the randomized MAC off, and then switch it back on, I still have exactly the same "random" address that I am required to have for all of time.
However, if you enable the developer options, you can find the option for "Wi-Fi non-persistent MAC randomization". It says "When this mode is enabled, this device's MAC address may change each time it connects to a network that has MAC randomization enabled."
(This is all on stock Android, on a Pixel phone.)
You shouldn't confuse the name of a setting with the behavior that setting controls. The name of the setting is lying to you.
Sqlite's "autoincrement" column modifier is another good example of this phenomenon. It's named "autoincrement", but as the documentation for the modifier notes, you will get autoincrement functionality on a primary key column regardless of whether that modifier is set, and the behavior controlled by the setting is something entirely different. ("Autoincrement" means that values in that column, once they have ever existed, may never exist in another row, even if the row in which they originally existed has been dropped. You may notice that this has nothing to do with the meaning of the word "autoincrement". Other people have noticed that too.)
Or adopt IPv6 with NAT64! All mobile devices support this now since many large mobile networks are adopting it, Apple requires apps support it to be approved for the App Store, etc.
"On Wednesday, Apple released iOS 17.1. Among the various fixes was a patch for a vulnerability, tracked as CVE-2023-42846, which prevented the privacy feature from working. Tommy Mysk, one of the two security researchers Apple credited with discovering and reporting the vulnerability (Talal Haj Bakry was the other), told Ars that he tested all recent iOS releases and found the flaw dates back to version 14, released in September 2020."
Makes you wonder if there’s anything else that might be missed.