Having had a day to reflect on this (including how it disrupted a vet’s visit for one of our dogs), I’m thinking this is not a time to revive marketing talk about the superiority of Mac/*nix over Windows. (Not that this post is doing that; thank you @mpainesyd !)
The latter may be highly vulnerable to a single blunder on one vendor’s part that can bring down a whole ecosystem of devices.
On Macs and MacOS derivatives, we have had our share of bungled and inadequately tested software updates whose effects ranged from functions temporarily disabled to entire devices “bricked” and requiring repair or replacement.
It’s a bigger issue about tech interdependence. My spouse and I were remarking at breakfast that we both know how to do “long division,” even though calculators and computers make that skill look obsolete. She said that the receptionist at the vet looked a little lost and flustered without use of the computer screen that is her constant work companion…but that she was amazingly personable without it as well.
I certainly agree whatever time there may have been for Mac/(Li/U)nix/Windows declarations of superiority are past. Each has seen some significant security problems issues. (I would argue that with respect to the OS as a data collection tool Windows is worse than macOS, and both are worse than most Linux distributions.) While my primary computer remains a mac, I’m currently typing on my travel laptop running Kubuntu 24.04 LTS, which has a delightful lack “OS as data collection tool” features, which I found particularly noxious in W11 (though with effort you can still install it without a Windows account).
More interesting to me was this, though:
China didn’t see much impact because they don’t use that for infrastructure. I’m sure their systems could see a similar set of problems if an internal supplier made the same sort of error, but it certainly does support the idea that it is a national security issue for all nations.
It’s a hard matter to balance the need for rapid deployment of security fixes vs appropriate testing prior to deployment.
(I’m glad I’m not the only one who can still do long division, too.)
Right. But there are vulnerable Windows users that need to beware Crowdstrike outtage scams.
“Researchers, including those from CrowdStrike intelligence, have thus far seen attackers sending phishing emails or making phone calls where they pretend to be CrowdStrike support staff and selling software tools that claim to automate the process of recovering from the faulty software update. Some attackers are also pretending to be researchers and claiming to have special information vital to recovery—that the situation is actually the result of a cyberattack, which it’s not.”
And while I have both Macs and Windows at work to support, our Macs also have the Falcon Sensor, a Crowdstrike product. Not affected by the fatal file pushed, but makes you wonder if a mac update to Falcon can do the same. Thankfully, I only had less than a dozen Windows I had to physically intervene with. One thing that did help, was Crowdstrike replaced the corrupt file with an hour, and computers that were rebooted and got their network stacks updated, would replace the file and back to normal login/use.
Well, it may not be putting your PC into a boot loop, but there may still be on-line services that became unavailable. My work computer didn’t fail, but our document management system was off-line for the day, so the document I was working on Friday won’t be checked-in until Monday morning.
Had to deal with repairing several co-worker’s Windows computers that were unable to boot because of this. (Mine crashed but was able to boot).
What struck me was how much easier it would have been to fix this on a Mac. The basic requirement was to a) unlock BitLocker and b) boot into Safe Mode so you could remove the the problem CrowdStrike driver.
First problem is that to change the boot settings, you had to enter a BitLocker recovery key – which the users did not backup. They had to retrieve it from their Microsoft account. On a Mac you can unlock FileVault using your admin password, even when you’re booted into recovery environments.
Second problem was starting up in Safe Mode. On Intel Macs this is as simple as starting up with the shift key held down. On Apple Silicon Macs it is harder, but not by much: Press the power button until you get to the startup options, then select the startup volume while holding the Shift key.
On Windows 10/11 this is much harder, when your Windows won’t boot. The problem is that you need to get to the Windows Recovery Environment, which is like the Mac’s recovery volume. Which key do you press to get into Windows RE? There is none. What you have to do is fail to boot three times in a row, then wait for it to try and fail to repair the startup, and then you’re in Windows RE. From here you select Startup Options, which gives a long list of ways to start, one of which is Safe Mode.
For one user, this still didn’t work – there was no Startup Options to pick. We struggled with trying to get this to work for hours. Nothing worked, including manual work-arounds that were supposed to get it changed to boot Safe Mode. It turns out that if your machine’s BIOS is set to use a RAID controller (even though you have no RAID!) then there’s no Startup Options on the menu. And some vendors ship their laptops with it set to RAID On, even with only one drive.
Note: I find the Windows 10/11 boot process unfathomable. Modern Windows uses the secure “Windows Boot Manager” to pick the startup drive, rather than the old UEFI or BIOS methods. Did you know that there is no GUI to select which Windows drive to start from, at all?
Wow. I didn’t believe that, but Microsoft says so too. If your computer can’t boot far enough to get to a desktop or login screen, then you have to go through that nonsense.
I remember years ago (maybe Windows 2000 or maybe older), that you could press a function key at the start of the boot sequence to get to the recovery menu. Microsoft was crazy for removing that mechanism.
I’ve been thinking about this, and it seems like the MacOS version of Falcon runs in userspace, not kernel space, since Apple has been aggressively deprecating kexts and every other means of modifying the kernel and boot process.
So I think that, while a bad update might have caused problems, it would not have caused a kernel panic / failure to boot.
That makes sense. One would have to presume that the perfect storm of a) poor validation on the creation of the configuration/update file, b) poor internal sanity checking on the file by the application that read it before acting upon it, and c) lack of adequate testing of the app with the updated file prior to its distribution, would be just as likely to occur on any platform running Falcon. But with less devastating consequences should it affect macOS because of this key difference between the platforms.