MAC Randomization Is Flawed: Proposed New Solution

General Discussion
1

TLDR: NetworkManager leaks MAC address. Can work around this by modifying drivers, which is feasible but requires infrastructure support from Qubes (QubesOS Contrib).

I recently set out to verify for myself that NetworkManager’s MAC randomization is implemented properly. I did this by reviewing NetworkManager, wpa_supplicant, macchanger, udev, iwlwifi, Linux kernel (cfg80211, mac80211, wired/wireless network driver implementation), iproute2, Tails, systemd and other codebases. I also read every Tails/Qubes/NetworkManager/other GitHub/GitLab issue that I could find on the topic.

My conclusion is that we can’t rely solely on either udev (Tails approach) or NetworkManager (Qubes approach) to ensure the true MAC address is never leaked. We must individually patch drivers to generate random MAC addresses instead of reading them from EEPROM. I agree this is not ideal, I wish we could’ve relied on one of the two existing solutions. With that said, it’s not as difficult as it might sound. Modifying the drivers to do what we need is quite easy, I have done it myself for a couple of obscure drivers already.

We can’t use the udev solution because it does not reliably handle suspend/sleep. Some drivers reset to the permanent (what I am referring to as true) MAC address during suspend. I can’t see that the Tails solution sets the random MAC again when exiting the suspend state. I can’t see an easy way to modify their solution to handle suspend, especially without race conditions. If there was an easy way to address this, it would be a better solution than NetworkManager although still slightly worse than modifying drivers because the true MAC is still accessible/readable.

The main problem with NetworkManager is that it brings the NIC into the ‘up’ state with the true MAC address prior to associating with a network. I reported this. You can read more details about why this is problematic in the report. They could change the code to not do this, but even if they make the change I would be hesitant to rely on NetworkManager for the purpose of MAC randomization. NM is a large and complex codebase, which does not put privacy first. Modifying the drivers, although tedious due to the large number of drivers, actually allows us to very easily verify that the MAC is not leaking due to the simplicity of the code that reads EEPROM and sets the permanent MAC.

An additional issue with NetworkManager is that it restores the true MAC address in many instances, such as when the device sleeps and when NM is restarted (typically done to apply an updated config). In the latter case a leak is guaranteed if the user is associated with an AP. With the modified drivers these issues would not exist.

I have managed to build a kernel with a modified driver using qubesbuilderv2, but this process required me to read (and modify!) portions of qubesbuilderv2. It also took a long time to run on my hardware. It’s definitely not something ends users should be expected to do, especially with each update of the kernel.

My proposal is that we come to an agreement on how we would like to structure all of this, and start supplying it to end users as a contrib package. The way I was intending to do it for my own personal use was to build the modified kernel and then set that only for my NetVM (setting it for all VMs would be bad as the modified driver could act as a fingerprint). If we are publishing it through the contrib system, there are a few other ways we could structure this. Deciding which of these is best needs to be discussed with the Qubes developers. Ideally whatever solution we choose should “fail closed”. So, if a driver hasn’t been patched then the unpatched driver should not load.

To clarify, the proposed solution is opt-in and users that want to rely on the existing NetworkManager-only solution would simply not use the modified kernel/drivers. In both cases users will still use NetworkManager’s randomization, just that one group is relying on it whereas for the other group it is a supplement.

Tails developers have recently been discussing MAC randomization and moving to NetworkManager. I have filled them in on my findings and proposed they get involved in the driver modification process. If the two projects and their communities are working together on this, we can probably cover the common drivers quite quickly.

For good measure, here’s a reference to Qubes’ main prior discussion on this topic

What do we think?

8 Likes
2

Here is another resource to consider:

@adrelanos

4 Likes
3

Can somebody please link this thread in the GitHub issue, as I can’t post due to account being created with Tor.

@marmarek You were involved in the original discussion, I assume you will be in support of this proposal?

1 Like
4

In order to get traction on this, I will commit to patching the 3 most popular wireless drivers. I guess this would be iwlwifi and 2 others. At this point, even if no further contributions are made this would still cover a large percentage of users and should require very little from the Qubes project other than telling me initially what the ideal way to structure these patches would be such that they can be added to a repository that will be built using QubesOS contrib infrastructure.

8 Likes
5

Managed to post on GitHub MAC Randomization for iwlwifi · Issue #938 · QubesOS/qubes-issues · GitHub

I’m not sure if @adrelanos has not seen this or just doesn’t have an opinion. Would expect this is something they would be concerned about.

The post got removed due to Tor. Here’s the contents:

This needs to be reoponed.

We can’t solely rely on NetworkManager, as they bring the NIC ‘up’ with the true/permanent MAC address in multiple situations. As originally proposed in this issue, patching drivers is the only way to do this without the possibility of leaks occurring.

I suggest that, for each branch in qubes-linux-kernel that we be build, we add an additional branch that includes patches for the wireless drivers. For example, for stable-6.6 we add a new branch stable-6.6-randmac. Other than the driver patches, we would need to modify the kernel build process so that it only includes drivers that haven’t been patched (fail closed). Alternatively this could be done outside of the kernel.

This would be an opt-in contrib package, so there’s very little maintenance required from Qubes, other than to get things started.

I have posted much more about this on the forum t/mac-randomization-is-flawed-proposed-new-solution and offered to patch the 3 most popular wireless drivers to get things started.

I can make the PR with what’s needed, I just need to know what will be accepted as I don’t want to waste time doing something be told it needs to be done differently.

2 Likes
6

Why not just use ethtool to modify the EPROM on the NIC?

1 Like
7

It’s uncommon for drivers to support this. If you search the Linux codebase for .set_eeprom you will see very few instances of it. It’s not supported in iwlwifi, for example.

2 Likes
8

@grandbronze111, on macOS running on real Apple hardware, the MAC address is able to be changed and survives both sleep and hibernation (but not a reboot). Since macOS is a UNIX-like OS, maybe this info could help

steps to change MAC address on macOS

  1. get the interface name of the Wi-Fi adapter (usually either en0 or en1)
    networksetup -listallhardwareports

  2. check the currently set MAC address (assuming en0)
    ifconfig en0 | grep ether

  3. set a new MAC address (make sure Wi-Fi is turned on first)
    sudo ifconfig en0 ether 11:22:33:44:55:66

  4. check that MAC address is changed (if not, re-run previous command)
    ifconfig en0 | grep ether

2 Likes
9

Thanks but it’s unrelated to the issue.

The only help I need is getting my solution into the Qubes contrib system. Not really sure why it’s so difficult to get a response from someone at Qubes (or even Whonix where this is considered more serious). I put in a lot of work and am willing to continue putting in the work, however it’s demotivating when people are just simply ignoring a legitimate issue.

2 Likes
10

I can’t comment much on the MAC problem but I think it is a big problem it’s not possible to anonymously contribute on github. USA is known to send to prison open source devs who work on privacy and freedom software. Being a qubes os contributor probably puts a big target on your back so it should be possible to anonymously contribute with Tor.

2 Likes
11

after a quick check, GitHub seems to work fine using Tor.

1 Like
12

I’ve always felt uneasy about the current state of MAC randomization. To me, this would be a welcome development.

3 Likes
13

Does it emit any kind of wireless packet with that MAC?

1 Like
14

This is not my experience. I have created 2 accounts in the past week with Tor and in one case I am told my account is marked as spam, and in another case my account appears fine but none of my posts appear outside of my account. There’s additional factors other than Tor. A bit off topic for this post.

With that said, if you have a working GitHub account would you please relay this post to GitHub? Even just a link helps.

Yes, as I’ve explained in the NetworkManager issue the NIC in the ‘up’ state can transmit packets.

In addition to what I’ve already explained, something new to consider is that relying on NetworkManager for MAC randomization only works for drivers that follow Linux network driver conventions. For example, drivers are told they should start the network hardware and enable tx/rx during ‘up’, but there’s nothing stopping them from doing this earlier (during USB/PCI probe for example) . In general a bad driver can leak the true MAC whenever, and NM is not in a position to do anything about it. By making these EEPROM changes to the driver, we not only solidify MAC leaking for good drivers, we also do it for bad drivers that don’t follow convention.

1 Like
15

I think @unman offers to act as a proxy to contribute on GitHub.

Maybe it can, but did you measure if it does?

I doubt qubes os is willing to integrate your change, the developers try to stick as close to upstream as possible. Maybe try to get your change into Linux or OpenBSD kernel, so it will be usable in sys-net and to everyone else.

I’m not saying your change is not useful, but I’m pragmatic and I know such change can be hard to get accepted. The best place for that would be to reach WiFi drivers/subsystems developers who have the knowledge to understand your change and potential side effects/consequences, and also the privileges to commit it if they value it as useful to everyone.

For qubes os, you could provide a kernel package with the change, as a short term solution.

3 Likes
16

Maybe it can, but did you measure if it does?

“Hey Qubes/Whonix users, the code tells us that your MAC can leak, but nobody had the time or equipment to measure it, so we didn’t deploy that solution preventing it. Sorry!”

I doubt qubes os is willing to integrate your change, the developers try to stick as close to upstream as possible.

In fact, it was Qubes’ lead developer who first proposed this solution of modifying the drivers. Qubes then went with NM because it claimed to handle this all, but as it turns out it doesn’t do it properly. It therefore makes total sense to revert back to the original proposal that, per marmarek, is a “surefire” strategy.

For qubes os, you could provide a kernel package with the change, as a short term solution.

This is exactly what I am proposing. I am not suggesting we apply this change as default, but offer it as an additional kernel that users can optionally enable. If you read my posts in depth, you will see that the entire purpose of this post was to discuss with a developer how they would prefer me to structure this package such that it will get accepted into the contrib repository. There are many ways to do it. I don’t have time to implement it multiple times over, as doing this development with Tor and cheap hardware is very slow. I’ve already put a lot of time into this research.

3 Likes
17

What are your thoughts on using a systemd service to randomize the MAC before the networking stack services are started. As far as it appears they are started after the root filesystem in mounted.

Thats what this script/project does: GitHub - RightToPrivacy/wipri: (Network Metadata Privacy) MAC Address spoofer with bonus combo (options): hostname + signal spoofer - *no disconnects!* Privacy Changing w/Brand Mimics: run as command or optional new randomized identity each boot; includes flags for continually changing random times/changing valid OUI addresses + Hostname randomizer + Device/Signal/location anonymization

As related to your Github account being marked as spam. If you are creating an account on Github via Tor you have to enable TOTP 2FA (use keepassxc etc.) or else your account will get marked as spam almost always.

2 Likes
18

What are your thoughts on using a systemd service to randomize the MAC before the networking stack services are started. As far as it appears they are started after the root filesystem in mounted.

The issue is that if the machine goes to sleep then some drivers will reset to the true MAC address and they won’t be set back to randomized on exiting sleep. There’s also the issue that NetworkManager still has access to the true MAC and can set it to the NIC such as when restarting NetworkManager to apply an updated config, and in other cases too.

As related to your Github account being marked as spam. If you are creating an account on Github via Tor you have to enable TOTP 2FA (use keepassxc etc.) or else your account will get marked as spam almost always.

I will try this. Thanks.

3 Likes
19

I think the lack of support from @adrelanos may have been due to an article that wrongly claimed MAC randomization is futile. I’ve debunked this here.

3 Likes
20

@adrelanos has shown support for this.

MAC randomization is a difficult topic. [2] [3] [4] [5] Implementations using NetworkManager and/or udev might, in theory, leak the original MAC address. This is because these are complex code bases with complex system interactions, where MAC randomization was not supported at the founding of these projects but bolted on later as an afterthought. Supporting MAC randomization at a different level, such as by the kernel, might be a more reliable approach to MAC randomization.

3 Likes