Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Wireless Networking Apple

Did MacOS Stop Allowing Changes to Wifi MAC Addresses? 118

ugen (Slashdot reader #93,902) writes: Something I discovered today, while trying to change a MAC address on a new MacBook Air (as I did for years on other MacBooks): ifconfig en0 ether "new mac" no longer works. It appears that this is a change made sometime last year, applicable to all Apple newer MacBooks.

Implications of permanently fixed MAC addresses on privacy and security are hard to underestimate. Given that Windows now supports complete Wifi MAC address randomization — I am sad to admit that Microsoft looks like a champion of privacy here. What are your thoughts? Solutions anyone knows of (I'll take a reasonable technical hack).

Here are a few mentions of this elsewhere:
Mac Rumors forums
The GitHub repo for SpoofMAC
A discussion on Stack Overflow

I've seen other theories about what's going on, though the bigger question is still what's the solution? Leave your own thoughts and suggestions in the comments.

And did MacOS stop allowing changes to wifi MAC addresses?
This discussion has been archived. No new comments can be posted.

Did MacOS Stop Allowing Changes to Wifi MAC Addresses?

Comments Filter:
  • by cdsparrow ( 658739 ) on Sunday October 06, 2019 @12:40PM (#59275922)

    but then chrome will eat your computer, lol.

  • USB wifi (Score:2, Funny)

    by OrangeTide ( 124937 )

    Oops you said it was a Mac.

    • Re: (Score:2, Insightful)

      by irving47 ( 73147 )

      Go back to 1995 when people gave a fuck about platform wars.

      • Are you implying that platform wars don't exist today? Normally I ask what rock you've been living under, but actually I have a more relevant question: How did you get internet access under that rock under which you so clearly still live!

      • Not much of a war when you only have two ports and you need to use one of them for charging.

  • Hm (Score:4, Informative)

    by pengeek ( 6294128 ) on Sunday October 06, 2019 @12:43PM (#59275934) Homepage
    Troubling if confirmed as not a bug, but doesn't seem to be in keeping with Apple's latest trend of privacy-as-a-service. Does seem to be true: https://forums.developer.apple... [apple.com]
  • Good change (Score:5, Insightful)

    by sentiblue ( 3535839 ) on Sunday October 06, 2019 @12:45PM (#59275942)
    The MAC address should have never been editable to begin with because it's a unique value only connected to the physical network device. Allowing the OS to change this value is a mistake and it should have been fixed decades ago.
    • Re:Good change (Score:4, Interesting)

      by Rosco P. Coltrane ( 209368 ) on Sunday October 06, 2019 @12:51PM (#59275968)

      This.

      MAC addresses are supposed to be hard-coded : first 3 octets are manufacturer ID, last 3 octets are device ID. Programmable MAC addresses have always been a hack - mostly useful to spoof another machine and bypass MAC-based security or get a fixed IP from a DHCP server that's meant to be doled out to another machine.

      Impossible-to-modify MAC addresse are the norm, not the other way round.

      • That's the theory, but I seem to remember there used to be mac conflicts back in the day with some card manufacturers. If you were in this situation with two cards with the same address, and couldn't change them, what would you do?

        • Address collisions are a reality, because the address space is just too small in today's world (kind of like people thought the IPv4 address space was inexhaustible back in the good ole days).

          But the reality is, they're very rare, even in large networks: the likelihood of one switch seeing two identical network interfaces with the same MAC is vanishingly small.

          • Re:Good change (Score:5, Informative)

            by Solandri ( 704621 ) on Sunday October 06, 2019 @01:30PM (#59276112)
            The first 3 ocets in the MAC address codes for the manufacturer, the last 3 octets code for the device ID. That gives enough addresses for 16.7 million vendor IDs, each getting to make 16.7 million devices. And most large manufacturers own multiple vendor IDs [github.com]. Cisco alone owns 819 of them, giving them 13.6 billion unique MAC addresses. Until we start making nanomachines with WiFi, there is no reason for a MAC address collision.

            IPv4 was limited to 4 bytes because (1) RAM was insanely expensive back then (graphics cards couldn't even display a monochrome bitmap graphic at full screen resolution because that would exceed the amount of RAM in the system - they used font bitmaps pre-stored in ROM to display text), (2), that was the length of a long integer back in the day (32 bits) and (3) "the Internet" was supposed to be a DoD network meant to survive a nuclear first strike. It wasn't meant to be inexhaustible, it was considered overkill for its intended purpose - it was highly unlikely the DoD and its contractors were ever going to exceed 4 billion computers. They never expected it to become The global standard for networking. And when they realized it was going to become that, they made IPv6, except nobody adopted it.
            • by guruevi ( 827432 )

              Every port on a modern switch can potentially need one or multiple MAC address. There's a load of virtual machines and virtual networking going on.

              Choosing a MAC address that will never collide with something else is near impossible.

            • RAM was insanely expensive back then (graphics cards couldn't even display a monochrome bitmap graphic at full screen resolution because that would exceed the amount of RAM in the system - they used font bitmaps pre-stored in ROM to display text),

              Perhaps it's time to replace that old VIC-20 with a shiny new VAX-11/780!

            • The need to set and change macs on virtual interfaces are there, eg when basing a new machine on a clone. The software layer needs to support it. Most hardware does. So there are privacy and technical reasons to want to change it. In general changing it is easy, so regardless of theoretical reasons to make it fixed, its too late to wind back the ability now and this is a step backwards for privacy and the utility of apple machines. I wonder if this limits the use of bridged networking with apple vmware gue
            • Until we start making nanomachines with WiFi, there is no reason for a MAC address collision.

              Incompetence. Accident. Miscommunication with contractors. There are probably loads more reasons why you could have a MAC collision. Are any of them good reasons? You could argue about that all day and it would still be irrelevant. The fact is that MAC collisions have occurred in the real world with zero MAC changes.

              It's also a fact that MACs are used for tracking, so this whole MAC collision argument is a red herring. That alone is a good reason to be able to change them.

              There were always means of changing

        • I believe this was usually due to counterfeit cards or dodgy manufacturers using other another company's MAC address range.

      • Re:Good change (Score:5, Informative)

        by Hizonner ( 38491 ) on Sunday October 06, 2019 @01:02PM (#59276018)

        Fully half of the MAC address space is reserved for "locally administered addresses". Meaning non-hard-coded addresses set by local administrators.

        It has always been that way, at least from day one of IEEE 802, and I think in the original Xerox Ethernet as well.

        Now get off my lawn.

        • Re:Good change (Score:5, Informative)

          by Junta ( 36770 ) on Sunday October 06, 2019 @01:30PM (#59276116)

          Well, *technicall* 25% of the macs, not half.

          To be concrete about things, the second to last bit of the first byte singifies whether the mac should be vendor based or local.

          Additionally, the last bit of the first byte of zero means unicast, and 1 means it is a multicast mac. So macs with first byte ending in 0b10 would be legitimate locally managed mac addresses to put on nics, but 0b11, 0b01, and 0b00 would not.

          • Interestingly, Ethernet demands that the bytes be sent on the wire LSB first. So, the multicast bit is in fact the first bit on the wire. A switch using cut-through could look at the first bit and quickly decide to just duplicate the bitstream to all other ports; otherwise it needs to look at the other 47 bits to decide what to do.
      • This.

        MAC addresses are supposed to be hard-coded : first 3 octets are manufacturer ID, last 3 octets are device ID. Programmable MAC addresses have always been a hack - mostly useful to spoof another machine and bypass MAC-based security or get a fixed IP from a DHCP server that's meant to be doled out to another machine.

        Impossible-to-modify MAC addresse are the norm, not the other way round.

        You probably never had to use DECnet,

        • DECnet predates Ethernet. It has literally nothing to do with 802.11.
          • by Hizonner ( 38491 )

            The DECNETprotocol used to run over Ethernet. And they did it by setting the MAC address to match your machine's MAC address. I'd forgotten about that.

            You sound really silly lecturing people who actually used the stuff, you know.

            • I was a DEC trained VAX/VMS system manager in charge of a heterogeneous PC/DEC corporate intranet in the 1980s. It did not rely on Ethernet only and could also use Token Ring, FDDI, and other data link protocols. You are the typical clueless slashdotter with no idea what you are talking about trying to sound skilled on subjects about which you clearly have no knowledge or experience.
              • by Hizonner ( 38491 )

                If you want to get in a pissing contest over it, I debugged implementations of that protocol. Among half a dozen other protocols.

                I never said it only ran over Ethernet. Regardless of what it ran over, it also ran over Ethernet. In fact, about 99.95 percent of the DECNET nodes that ever existed were attached over Ethernet, or over some other link layer that used essentially the same MAC format. It used the essentially identical MAC hack on all the other media you actually mention, which share the same MAC ad

                • It's great that you can google and put together a bunch of information that would make someone who didn't understand the stupid statement you made in the first place think you know what you were talking about.

                  "The DECNETprotocol used to run over Ethernet. And they did it by setting the MAC address to match your machine's MAC address. I'd forgotten about that.

                  You sound really silly lecturing people who actually used the stuff, you know.

                  Now lets look at how we can easily tell that you had no idea about any o

                  • Ethernet II was an industry standard promoted by DEC and 3Com, among others. When the IEEE decided to add this to the 802 group, as a matter of political necessity, the new standard had to be somewhat different to the existing Ethernet II, in order to deny a commercial advantage to the incumbents. And so it happened. Although, the standards mostly interoperated, so Ethernet II could connect to 802.3/802.1. However, changes had to be made by DEC etc. to their equipment in order to market their stuff as IEEE
                  • Now lets look at how we can easily tell that you had no idea about any of what you just wrote prior to your current research. DEC systems didn't have a MAC address, NICs do. It makes absolutely no sense to claim that one sets a NIC address to the "machines MAC address" and such a statement represents an admission that you have no idea what a MAC Address [wikipedia.org] even is.

                    This is being pedantic - it's obvious what the parent poster intended when he made his statement, and I have no doubt he knows what

                  • by Hizonner ( 38491 )

                    Ah, good morning. Yes, I guess I could be totally ignorant, or there's the more obvious possibility that I could have accidentally typed "setting the MAC address to match your machine's MAC address" when I meant "setting the MAC address to match your machine's DECNET address". That could have happened too. I mean, if you saw a sentence that was nonsensical on its face, you could have quoted it and said something about it.

                    They changed the MAC address to match the assigned network layer address because there

                    • "I mean, if you saw a sentence that was nonsensical on its face, you could have quoted it and said something about it."

                      Consider it done,as I just did exactly that. You wrote an extremely short post consisting of a ridiculous statement followed by a suggestion I was the one that looked silly. Now to be fair, I could have said "The proprietary CDMA based protocol that DECnet used and also called Ethernet predates what we currently refer to when we say Ethernet, and tells us nothing of value about how Ethernet

                    • by Hizonner ( 38491 )

                      I thought I had admitted that I said something nonsensical. I don't know about "ridiculous"; I don't think it made enough sense to be ridiculous. "Set the MAC address to the MAC address"?

                      As for the rest, I don't know what you mean by "addressing scheme". The address format is 48 bits, first bit being unicast/multicast, second bit being local/global, and in the case of global addresses, the next 22 bits being the OID and the remaining 24 being the device ID. Do you think it's a coincidence that 802.11, 802.3

                • ... I imagine DECNET probably had some way to run over serial, with HDLC or something like that; I never got involved in that and don't recall. Such serial protocols may have, and indeed probably did, predate Ethernet...

                  DECnet used the DDCMP protocol, not HDLC, to run over serial links. It was developed in the mid-1970s and needed to work using existing serial interfaces, hence could not use the bit-stuffing of IBM's DLC. I was the junior member of the committee--my job was to take the current draft protocol, implement it, and bring the results back to the next meeting. It was becuse of my work that we added a checksum after the header of the data message. If a transmission error changed a high-order bit of the count f

              • by Khyber ( 864651 )

                The DECNet protocol on my old AS/400-powered network system ran over fucking Ethernet and TwinAX.

                You must have been a poorly-trained manager (as most managers tend to be, they're usually only in management so they don't fuck things up. As the saying goes, promote the incompetent to management, keep the competent people on the actual floor doing real work.)

                • "The DECNet protocol on my old AS/400-powered network system ran over fucking Ethernet and TwinAX."

                  The systems I managed also ran over something called Ethernet that was actually a proprietary DEC protocol and was not, nor could it be, the Ethernet (802.3) about what we were discussing. Of course we were talking about DEC and you just pulled an IBM system out of your ass. ROTFLMAO.

                  "You must have been a poorly-trained manager (as most managers tend to be, they're usually only in management so they don't fuck

        • As other replies show here, DECnet is not something you can get away with mentioning in polite company. Strangely this is the second time I see that beast to be mentioned in the last week. If we mentioned it a third time I am afraid every neck bearded hipster would start to use it on their Sinclair Spectrums...
          As obvious I used to wrangle DECnet setups and unfortunately miss those good old days when you need a drill to tap a new terminal or a DECnet bridge to Ethernet cable. I personally do not like MAC a
      • Re: (Score:2, Insightful)

        by Hizonner ( 38491 )

        Oh, and by the way "MAC based security" is a hack mostly used by incompetent morons, because it is not and can never be reliable. The rest of the world isn't obligated to support your halfassed kludgery.

        • Re:Good change (Score:4, Insightful)

          by drnb ( 2434720 ) on Sunday October 06, 2019 @02:40PM (#59276278)

          Oh, and by the way "MAC based security" is a hack mostly used by incompetent morons, because it is not and can never be reliable. The rest of the world isn't obligated to support your halfassed kludgery.

          Its one tool in the toolbox and hence useful. Many useful things are not 100% reliable, DNS for instance, it can be hijacked. Its only a problem when a person thinks its a complete security solution rather than one piece of a larger solution.

          • Its one tool in the toolbox and hence useful.

            No, it isn't. It's worse than worthless because it gives you a false sense of security.

            DNS for instance, it can be hijacked.

            And therefore it is untrustworthy, and that's why DNS-over-HTTPS is now a thing. (And DNSSEC, and dnscrypt...) Nobody should be using ordinary DNS for anything any more.

            • by drnb ( 2434720 )

              Its one tool in the toolbox and hence useful.

              No, it isn't. It's worse than worthless because it gives you a false sense of security.

              And yet quite pickable locks keep a whole lot of unwanted people out every damn day.

              • And yet quite pickable locks keep a whole lot of unwanted people out every damn day.

                This isn't a lock. And a lock doesn't keep anyone out by itself. Defense in depth does that. The lock is just there to slow people down, or to make them make noise getting in, to aid in detection. It was never intended to keep people out. A good lock plus bars and the like can keep people out, but MAC filtering never will.

                • by drnb ( 2434720 )

                  And yet quite pickable locks keep a whole lot of unwanted people out every damn day.

                  This isn't a lock. And a lock doesn't keep anyone out by itself. Defense in depth does that. The lock is just there to slow people down, or to make them make noise getting in, to aid in detection. It was never intended to keep people out. A good lock plus bars and the like can keep people out, but MAC filtering never will.

                  MAC filtering keeps the low skilled out.

                  Regarding defense in depth, I wrote above that MAC filtering is just one tool in the toolbox, one piece of a larger solution. As a simple lock is one piece of a larger solution.

              • Mostly by convention, and because these people would most likely also not enter your home if you didn't lock the door at all.

                • by drnb ( 2434720 )

                  Mostly by convention, and because these people would most likely also not enter your home if you didn't lock the door at all.

                  Untrue. Unlocked doors, open windows, etc, increase the problem. In particular for cars which have even easier to defeat locks than homes.

      • Re:Good change (Score:5, Insightful)

        by spire3661 ( 1038968 ) on Sunday October 06, 2019 @01:46PM (#59276148) Journal
        Its like you forget the purpose of the OS is to abstract the hardware. There is nothing wrong with ordering the OS to display a different MAC address if i command it to be so. The PHY layer may be hardcoded, but the OS doesnt have to respect it and can output any number the operator chooses. Its not your place to judge or moralize how i command my OS to abstract the hardware..

        The only hack here is you.
        • It's like you forgot the purpose of the OS is to abstract the consumer's money from their wallet. There is nothing wrong with ordering the OS to display a different MAC address if the customer submits a valid micropayment. The PEBKAC layer may be hardcoded, but the OS doesn't have to respect it, and can output any number we choose. It's not your place to judge or moralize how we command our OS to abstract your money.

      • They are a _useful_ hack, one that is available to most other operating systems. That "bypassing DHCP reservation based MAC security" has been useful for a host to resume the identity of the host it replaces. Disabling it without notification is disturbing.

      • by LiENUS ( 207736 )

        MAC addresses are supposed to be hard-coded : first 3 octets are manufacturer ID, last 3 octets are device ID. Programmable MAC addresses have always been a hack - mostly useful to spoof another machine and bypass MAC-based security or get a fixed IP from a DHCP server that's meant to be doled out to another machine.

        The problem with that theory is there is such a thing as a locally administered MAC address akin to rfc1918 but for MAC addresses and is a perfectly legitimate use case for alterable MAC addresses.

      • Comment removed based on user account deletion
      • by mysidia ( 191772 )

        because it's a unique value only connected to the physical network device.

        Who are you to say really? Sometimes the network admin may decide to assign their own MAC addresses -- for example, make the MAC follow the user particularly for highly secure environments.

        The standard even provides a mechanism for this. its called the Locally Administered MAC Address bit [noah.org] -- The second bit of the first byte of a MAC address determines the type of OUI. If the bit is 0 then it is an OUI globally assigned by the IE

      • by segin ( 883667 )

        Programmable MAC addresses have always been a hack

        DECnet [wikipedia.org] used to use programmable MAC addresses to avoid the need for an address resolution protocol when using Ethernet as the physical layer.

    • The MAC address 1.) should have never been editable to begin with because it's a unique value only connected to the physical network device. 2.) Allowing the OS to change this value is a mistake and it should have been fixed decades ago.

      Reasons?

      • Re:Good change (Score:5, Insightful)

        by AleRunner ( 4556245 ) on Sunday October 06, 2019 @01:20PM (#59276088)

        Reasons?

        a) If you are the Chinese government then it's important to know which citizens had which IP address since otherwise they could spread unseemly propaganda like claiming that there was a "massacre" in some Tienanmen Square when everybody knows that it was just some silly students committing suicide by jumping under tanks. Instead of allowing that you can help these misguided people by sending them to a nice friendly "reeducation" camp where they can enjoy watersports and new techology. Luckily with fixed MAC addresses and access to the logs of WiFi routers this success is guaranteed.

        b) If you are an data broker helping advertisers spy on people then you can use contracts with WiFi providers to match MAC addresses to IP addresses. This can be even more useful if you can then match them with people using specific VPNs and do traffic analysis on them. Specifically, some people clear their cookies and stuff from time to time to achieve privacy. If you know their cookie and MAC address before a clearing and their cookie and MAC address after a clearing then you can see that the MAC address is the same and use it to know that the cookie belongs to the same person. This is especially valuable because they are clearly a person who doesn't want to be monitored, so its likely other data brokers won't be able to match them as one person so advertising agencies will pay you extra.

        c) if you are a dead person who set up a router with MAC address filtering then it might happen that someone wants to update their hardware and use a new MacBook to replace their old broken one. However, when you set up the MAC address filtering that laptop didn't exist so it's hardly fair if they allow it to access the network now. If people could change their MAC address they would just do it and forget about the issue as they happily use the network you set up. If

        d) if you are an advertiser and you can check that their connections come from a unique MAC address then you can be sure that it's a real person with a real computer and target them with malware and other standard advertising things without losing money on fakers who pretend to be

        As you can see, there are lots of valuable reasons to stop people from changing their MAC addresses.

    • Found the guy who apparently has never configured VMs or containers.

      Suggestion: go read the data sheets for the Intel 82599 or Intel XL710 chips and then come back to us and pronounce what the OS should and shouldn't do.

      • by sconeu ( 64226 )

        Wrote a boot rom for a system with an 82593 based ethernet. The first thing you did was to tell the chip what its MAC address was.

    • by Nkwe ( 604125 )

      The MAC address should have never been editable to begin with because it's a unique value only connected to the physical network device

      It is unique until it is not. I have come across multiple network cards that had the same MAC address. Sure it is not *supposed* to happen, but manufacturing errors do occur. Note that a MAC address is 6 bytes of which the first three are the vendor identification. This leaves the last three bytes or only about 17 million unique addresses per vendor code. If a vendor builds more than 17 million cards (network interface chips), they can probably get another vendor id associated, but some may take a shortcut

    • by johnnys ( 592333 )

      Not true. The ability to change a MAC address on a system is a very valuable feature, not a bug.

      The MAC address should be editable: How else can you preserve your anonymity on a subnet? There are legitimate requirements to be able to put a system on a network without being tracked, or deploy honeypots in VMs without being easily identifiable to villains: It's needed for security researchers in the free world and for dissidents in the less free world.

      Besides that, with software-defined networking how are you

      • by Megane ( 129182 )

        With IPv6, the MAC address is part of the provisioned IPv6 address

        There's already a protocol to use a random local part for an IPv6 address (RFC 4941?), and it's usually enabled by default. And it can even generate a new address every now and then.

        I have a Uverse router which caches EVERY IPv6 address a computer has ever used, can report ALL of them for local DNS queries, and there is no apparent way to clear that cache. (this isn't the only quirk in its firmware) This can cause a computer to try (and fail) to connect to an expired IPv6 address, so I have to disable it o

    • by Z00L00K ( 682162 )

      Editable MAC addresses do have a use when you run high availability clusters though.

      As for "privacy" it's only visible on the specific subnet, never over the full internet so it's only when at airports or other public places that the extremely paranoid need to mess with it.

      • I suppose it could be incorporated into a browser cookie that's sent back to some website as well, no?

        But I think that what everybody here has missed is that it's a "MAC address". Probably some IP legal mind at Apple saw "MAC" and said "Hey - we own the trademark - let's put an end to this counterfeiting at once!" And some poor schlub of a programmer said "Yes, Boss".
    • by Anonymous Coward

      Absolutely silly.

      I guess we'll just ignore that every VM has virtual hardware, created by an OS? Or that a NIC doesn't even have to be a piece of hardware?

      Allowing people to edit a MAC, is just allowing people to do what can already be done. And is done.

    • The MAC address should have never been editable to begin with because it's a unique value only connected to the physical network device.

      Duplicate MAC addresses can be useful in active/standby, fault-tolerant, and/or high-availability configurations on individual (non-cluster) systems.

      A while ago I was an administrator for a bunch of HP 9000 series systems (3 T-600, 1 K-460, 1 D-380, 3 A-Class, 3 L-Class, 3 N-Class) running HP-UX 11 and several had redundant NICs that could be configured with the same MAC for fail-over conditions. (Several also had redundant SCSI controllers attached to AutoRAID units and EMC-3500 or HP-XP256 storage uni

      • Duplicate MAC addresses can be useful in active/standby, fault-tolerant, and/or high-availability configurations on individual (non-cluster) systems.

        This. If a device takes over the IP or VIP address of a cluster or failed peer but does not take over its MAC, it will take some time for other devices ARP tables to reflect that change which does not make for a very seamless failover.

        You are much more likely to see duplicate MACs on a segment as a result of software or configuration errors than to ever see two real hardware MACs collide.

    • The MAC address should have never been editable to begin with because it's a unique value only connected to the physical network device

      That's a good 1/3rd of an argument. Now you need to come up with why (other than to track users) having this unique value is necessary for a functioning network. When you answer consider the fact that switches and routers dynamically handle this whenever a device is plugged in and that everything else is under the control of administrators.

    • The MAC address should have never been editable to begin with because it's a unique value only connected to the physical network device.

      HAHAHAHAHAHHAHAHAHAHAHAHAHA

      MACs have never been unique. People have had MAC collisions in the real world. Comment invalidated due to spectacular ignorance.

      • Facts don't change because you mod down the person who shares them with you. And the fact is that MACs are not and never have been unique, and anyone who thinks they are has no fucking clue what they are on about. They were supposed to be, more or less, but they are not.

        • And the fact is that MACs are not and never have been unique

          The first one was. Dunno about the second.

    • by sjames ( 1099 )

      A large chunk of the MAC address space is reserved for local administratively assigned values [wikipedia.org]. That suggests that MAC addresses were always meant to be changeable. If not, why was so much of the address space dedicated to that?

    • That is true for "universally administered addresses" (UAA). But there are also "locally administered addresses" (LAA). The difference is determined by the second-least-significant bit of the first octet of the address. So you can make a dynamic or locally-administered address as long as you make sure the second-least-significant bit of the first octet of the address is a 1.
    • by AmiMoJo ( 196126 )

      We made a lot of mistakes when it comes to protecting privacy, and fixed IDs is one of the biggest.

    • The MAC address should have never been editable to begin with because it's a unique value only connected to the physical network device. Allowing the OS to change this value is a mistake and it should have been fixed decades ago.

      Android 10 uses random MAC addresses by default.

  • by carlhaagen ( 1021273 ) on Sunday October 06, 2019 @12:52PM (#59275976)
    Lappy:~ ch$ ifconfig en0 | grep ether
    ether 14:c2:13:35:17:5e
    Lappy:~ ch$ su bigboyadmin
    Password:
    bash-3.2$ sudo ifconfig en0 ether 14:c2:13:12:34:56

    *toggled wifi off/on*

    bash-3.2$ ifconfig en0 | grep ether
    ether 14:c2:13:12:34:56
    • How on earth is this marked as insightful or interesting? MacOS 10.12 came out in 2016. This would mean that you got your MacBook Air in the first 2 quarters of 2017 and you haven't updated it since. MacOS 10.14 came out a year ago and 10.15 is due any minute now. What does a 3 year old OS have anything to do with what MacOS is doing now?
  • Maybe Catalinaâ(TM)s shell change is the reason Â\_(ãf)_/Â
    • Usually you set the Mac address with a tool like ifconfig, not with bash. Although you can use bash to run the ifconfig tool, that shouldn't make a difference.
    • Not sure how this idea worked out in your head. It's not the shell doing the change, it's the program called by the shell (ifconfig) doing it.
  • I'd be willing to argue that over 95% of Apple's customers have no need to spoof a MAC address or even know how they would have done it.

    For the 5% that need to do so, well, those people probably have dual-boot set up with an OS that lets them do what they will.
  • And did MacOS stop allowing changes to wifi MAC addresses?

    I can change it on my Mid-2014 MBPro, running Mojave 10.14.6. (Yes, I know the article is talking about newer MBPros.)

    Can also change it on a Late 2012 Mac Mini, also running Mojave 10.14.6.

    So it's clearly not a MacOS limitation.

    • Can also change it on a Late 2012 Mac Mini, also running Mojave 10.14.6.
      So it's clearly not a MacOS limitation.

      This is about a newer version of MacOS, so your anecdotes are inapplicable. Anyway, it looks like it was a real problem, but they fixed it in the very latest version.

  • Already Fixed (Score:5, Informative)

    by gabebear ( 251933 ) on Sunday October 06, 2019 @01:30PM (#59276114) Homepage Journal
    It looks like the newest MacOS(Catalina) re-enables changing the MAC on the machines that it wasn’t working on. https://github.com/feross/Spoo... [github.com]
    • Yep, working here on Catalina GM1 (zsh shell)

      Peters-MacBook-Pro:~ peterglock$ sudo ifconfig en0
      Password:
      en0: flags=8863 mtu 1500
      options=400
      ether f0:18:98:24:31:b2
      inet 10.0.9.114 netmask 0xffffff00 broadcast 10.0.9.255
      media: autoselect
      status: active
      Peters-MacBook-Pro:~ hack101$ sudo ifconfig en0 ether f0:18:98:24:31:b3
      Peters-MacBook-Pro:~ hack101$ sudo ifconfig en0
      e

    • It looks like the newest MacOS(Catalina) re-enables changing the MAC on the machines that it wasn’t working on. https://github.com/feross/Spoo... [github.com]

      That's good, but Apple should add an option for automatic MAC address randomization. And probably turn it on by default.

  • by Solandri ( 704621 ) on Sunday October 06, 2019 @01:39PM (#59276136)
    Most WiFi chipset vendors (including Intel) prohibited changing the MAC address in software nearly a decade ago to prevent WiFi ID spoofing attacks, where someone else connects posing as you. Apple is just late to the party. IIRC, it's why we're using WPA2. The original WPA was compromised by spoofing the MAC address of someone authorized to be connected so the router would respond to you. You'd send a bunch of queries to the router and recording the encrypted responses to help figure out the security key.
    • > Most WiFi chipset vendors (including Intel) prohibited changing the MAC address in software

      Really? Can you name any such vendors? Because they sound like vendors to avoid.

    • Considering how crappy most APs are, from APs that make nonce renew trivial to those that "generate" their nonces by simply adding 1 to the previous one, connection riding is a reality with most PSK secured APs today, too.

      If my neighbor had his AP turned on more reliably, I would have canceled my ISP contract by now.

    • I don't mean to be rude, but can you provide some sort of proof of your statement that "Most WiFi chipset vendors (including Intel) prohibited changing the MAC address in software nearly a decade ago"? This directly conflicts with my lived experience.

      I mean, I routinely change the MAC addresses on my personal machines as part of initial setup. I've never once run into a system where this was not possible.

      PS: Not inexperienced. I'm a working computer scientist today, and wrote my first code shortly before

  • MAC addreesses are unique IN A LOCAL AREA NETWORK (LAN). They are meaningless and of no value (worthless) outside that LAN. Security "researchers" who breathlessly decry sharing MAC addresses are clueless.

    This is the real nothing-burger.

    E

  • I do remember where with some cable modems, it used to be you had to spoof their MAC as the MAC of your router attached to it, if you wanted to successfully share multiple devices on the connection. Of course, that was back in the early days of broadband, where cable providers actually thought most home users would simply be attaching a single PC to the back of the modem to use it. "Advanced users" sharing a house full of devices though it were supposed to pay more for a "business class" combo cable modem and router that would allow it.

    But I fail to see why this is a "big deal" if Apple stopped allowing modifying the wi-fi NIC's MAC in the OS? The only recent use-cases I've had for editing a MAC address were on Windows servers running expensive software that had licensing partially linked to the MAC address of the NIC card. When we virtualized those systems or moved them to new physical servers, it was easier to clone the MAC of the previous server than to go through all the hassles involved in requesting a new license key to re-activate the product.

    Again, even in edge-cases like these, you're really not talking about the *wireless* adapter. You're dealing with the wired one.

    If your concern for editing the wi-fi MAC address on your Mac is simply to get around MAC address filters? Well -- I'd say #1, that must mean you're doing things you're not supposed to be doing on that network, or else your MAC wouldn't be in their block list. But #2, if you do have an occasional to regular need to do such a thing? Sounds like it wouldn't be a terrible idea to just use something like an Apple Airport Express that you could attach via a wired Ethernet connection and let it establish the wi-fi connection for you?

  • Implications of permanently fixed MAC addresses on privacy and security are hard to underestimate.

    This literally means the implications are so minor that you can hardly underestimate them. Like, so minor that we shouldn't even be discussing them.

    • Implications of permanently fixed MAC addresses on privacy and security are hard to underestimate.

      This literally means the implications are so minor that you can hardly underestimate them. Like, so minor that we shouldn't even be discussing them.

      Well count yourself lucky that I don't have mod points right now!

  • That means however low you estimate the implications, they will be less.
  • Every time I get a new Mac or update/reload my OS, I set the MAC address so that the statically assigned DHCP lease on my router assigns the right IP to my Mac.This way, I get the same local IP from my router every time, and don't have to frequently update all those nice forwarded ports for my VPNs, VOIP/SIP accounts, home security software, SONOS media remote sync, etc. Now I upgraded to Mojave where mommy and daddy (who are both Tim Cook) decided I don't get those privileges anymore. This always worked, u
  • "I am sad to admit that Microsoft looks like a champion of privacy here."

    I am sad to know that you think only MS has an alternative here.
    When thinking about privacy, I tend to think about certain OSS OS's.

If the facts don't fit the theory, change the facts. -- Albert Einstein

Working...