Posting this link here as it is very relevant to Qubes Whonix users.
Would appreciate your support on the original post @adrelanos as it is less likely to gain traction otherwise. I am unable to attach it to the GitHub issue as my account is marked as spam due to Tor usage.
@Patrick I would like to ask that we update Whonix documentation with a link to my Qubes post.
If you don’t care to show your support for my solution, at the very least you should warn your users of this flaw.
I suggest posting in the Kicksecure Forums as well:
related:
@Patrick, please don’t assume I am just some passerby offering up a half-baked solution to an unsolvable problem. I have researched this topic thoroughly and my solution has merit and should be given a fair chance to receive your support.
I am aware of that article stating that randomizing MAC is futile. The article does have some merit, but there are inaccuracies in it and to say randomization is futile is nothing more than clickbait.
I do agree with the article’s claim that there are properties of the hardware that allow a NIC to be identified and subsequently tracked across locations. There is nothing MAC randomization can do about this, and this is likely an unsolvable problem.
The issue of revealing the NIC’s true MAC is separate. An AP being able to fingerprint a NIC AND obtain its true MAC is much worse than being able to fingerprint the NIC but not get access to its true MAC. As a concrete example, let’s say I am unable to purchase a computer without being on camera. I am able to use a long-range antenna to connect to a public AP. If that AP is later queried for information about who was connecting, them handing over the true MAC would mean I’m screwed, but just the fingerprint would mean they could only learn about other access points I’ve connected to in the worst case. It’s not like these NICs are being fingerprinted and stored in a database as they leave the factory. This isn’t even to mention that, practically speaking, many APs are probably not performing this fingerprinting, whereas there’s no doubt they are logging the MACs.
That article’s claims about revealing the true MAC in section 6 are completely false, even with NetworkManager randomization. And they’re especially false with my proposed fix.
The content at MAC Address - Whonix is not really applicable. Again, even NetworkManager randomization solves these.
Unfortunately, a viable solution requires manufacturers to modify drivers or firmware of their hardware products to add privacy preserving mitigations.
This is what Kicksecure say about this, which supports that my solution is the proper way to do this.
I would appreciate if you could reconsider showing your support on my Qubes forum post.
Can somebody please link this thread in the GitHub issue, as I can’t post due to account being created with Tor.
I didn’t say that it is incapable of leaking the MAC address. I don’t know. I asked for examples of how can it happen. I don’t think nobody is willing to work on something unless they think it’s useful.
At the very least, this is useful for majority of Qubes/Tails users.
BTW, if we’re only talking about WiFi, a good solution good be to expand the behaviour of wifi.scan-rand-mac-address.
This sounds like a good idea based on my understanding of how everything works. How difficult do you believe it would be to implement this? I can potentially work on this in the future, but I would want to consult with someone more familiar with NetworkManager’s architecture to come up with an implementation plan.
This approach could be perceived as a pattern where implementation-related discussions gradually shift responsibility to developers. Discussions should aim to empower contributors to take action rather than unintentionally placing the burden on upstream developers.
I don’t have time to implement something multiple times over because the design was wrong from the start.
I understand that your time is valuable. However, time is a constraint for everyone involved. If you communicate upfront that you have limited time, upstream might deprioritize collaborating effectively.
My recommendation: Contribute a few small patches upstream on unrelated but helpful topics that require little or no support. Having a track record of successfully merged patches, regardless of the specific Open Source project, can build trust and increase the chances of extended support during your more significant contributions later.
I don’t know if Qubes is willing to carry kernel driver patches, even if contributed. This is because the kernel changes over time, Qubes needs to rebase to newer kernel versions, and updating the patches might require ongoing maintenance effort. You need to ask Qubes. Potential appropriate venues might be the qubes-devel mailing list, Qubes GitHub, and/or Matrix channel. To increase the chances of a timely reply, it might also be helpful to be already known as someone who landed a (small) patch in Qubes before.
Needless to say, if such patches were merged upstream in Linux, that would avoid the patch rebase issue but may be even more difficult.
Providing examples of kernel drivers you’ve already patched could help demonstrate feasibility and build confidence in the proposed approach.
These non-technical comments of mine are just my opinion. Take them with a grain of salt. I might be wrong.
To show my support for any MAC randomization improvements, here is something you can quote:
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.
[1] Wiki History
[2] MAC Address - Whonix
[3] MAC Address - Kicksecure
[4] Dev/MAC - Whonix
[5] Your MAC Address Randomization attempts are futile!
Could you clarify which specific flaw you’re referring to?
Since you wanted to contribute, editing the wiki is one way.
I think the documentation, specifically when factoring in Tor entry guards, looks complicated enough to know that MAC randomization might be nice but not something to rely on. Quote:
TODO: Please help test and improve these instructions.
This quote expresses that the wiki page could benefit from further refinement and testing to improve clarity and reliability.
That is the one to focus on. If you could contribute that, it would be helpful. Upstream already gave a green light on its usefulness and said, “patches welcome.”
I looked into this and I could implement it, but it only improves the situation and doesn’t make it “surefire”. From my original post:
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.
My recommendation: Contribute a few small patches upstream on unrelated but helpful topics that require little or no support. Having a track record of successfully merged patches, regardless of the specific Open Source project, can build trust and increase the chances of extended support during your more significant contributions later.
I’ve contributed to Qubes, Whonix and Tor Browser before. I use these daily and always try to improve them for myself and others. I don’t like to create a linked history of all my work as that could result in me being a target.
I don’t know if Qubes is willing to carry kernel driver patches, even if contributed. This is because the kernel changes over time, Qubes needs to rebase to newer kernel versions, and updating the patches might require ongoing maintenance effort. You need to ask Qubes.
My recommendation was to put these into a Qubes contrib package, which is community maintained. It would be up to the community to modify the drivers as the kernel is updated. I intend to keep the drivers I use up to date for as long as I use Qubes, which is likely “forever”. I’ve also informed Tails that their current solution has issues and that they can’t rely on NM either, so it’s possible they will get involved with driver modifications at some stage. The thing is, most drivers assume that the MAC address stored in EEPROM may be invalid, and they have a path to randomly generate it in this case. So the modifications are usually as simple as forcing this path every time, which only requires changing one or two lines of code.
Needless to say, if such patches were merged upstream in Linux, that would avoid the patch rebase issue but may be even more difficult.
Can’t see it happening.
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.
Thanks, this is really appreciated.
Could you clarify which specific flaw you’re referring to?
I was referring to the flaw which is that the MAC address can still leak despite NetworkManager being configured with randomization.
Since you wanted to contribute, editing the wiki is one way.
I will add everything to the Whonix wiki once I know whether we will get support from Qubes. If Qubes does not give us support I will post the instructions for compiling the modified kernel locally, but this is a really bad way to do it for multiple reasons.
Dev/MAC - Whonix new wiki chapter: Leak-proof MAC Randomization - Technical Implementation Challenges
MAC Address - Kicksecure updated wiki chapter: MAC Spoofing Warning - Added:
Warning: MAC randomization might be unreliable. There are Leak-proof MAC Randomization - Technical Implementation Challenges. Whonix might have Reliable IP Hiding but there is no similarly dedicated, actively maintained, well tested MAC randomization project.
From my perspective, I am engaging with a pseudonymous individual without prior history.
My additional recommendations are as follows:
I’m a bit confused?
So tails doesn’t use NetworkManager for spoofing, they use macchanger.
They then use a script that detects if the generated randomized MAC addresses NIC part is the same as the real one and re-generates it if it matches.
That is one thing that NetworkManager doesn’t do and in fact there is a issue here about it:
gitlab .freedesktop.org/NetworkManager/NetworkManager/-/issues/1680
However I’m confused as to how your stating the NIC leaks? I’m not doubting since NetMananager has had issues and if you don’t put connection.stable-id=${CONNECTION}/${BOOT} in the config file it will revert back after sleep/suspend.
Are you referring to WiFi scanning cause that’s the only part I guess tails relies on where it changes sending out a scanning beacon its random and different then the one set by macchanger.
Or are you saying this leak is something that can’t be seen or observed in the operating system but rather by viewing packets (e.g. wireshark)?