by pbrw on 7/19/24, 10:31 AM with 48 comments
by wkat4242 on 7/19/24, 11:15 AM
Of course something like an EDR requires kernel level access otherwise it's too easy to bypass. But Apple has system extensions as a useful compromise. They're basically kernel level APIs that can be called by validated signed software. I think it's a good alternative to just allowing random code to run in the kernel.
The thing is, Apple has a habit of going to software vendors and saying: "We're changing this next year. There'll be a 2 year deprecation period and after that we'll lock you out. So change up or die off. We don't care."
Microsoft doesn't really do this and even if they do there's a lot of ifs and buts. They're much more receptive to the concerns of legacy software vendors because they represent a much bigger share of their market and the customer base (enterprise market) that cares about legacy is also very big and vocal.
Needless to say this is also the customer base that got heavily hammered by what happened today. But nobody thinks about that until it actually happens.
by tredre3 on 7/19/24, 7:36 PM
It absolutely would. Windows is way ahead in terms of driver isolation and stability. Most drivers cannot bring down the system (your GPU driver can crash, your screen will flicker and maybe apps that were using it will crash, but the system recovers). Not so on Linux unfortunately, any driver will bring the system down.
More recently certain class of drivers have been making use of ebpf or virt2, which helps in isolating the driver. But I know for a fact that CS on Linux is as low level as it can be.
So long story short only MacOS is resistant to this, because they've simply deprecated any third party kernel extensions/modules.
by Nordoz on 7/19/24, 10:45 AM
by orbital-decay on 7/19/24, 7:41 PM
If you're sure you don't want to freely use your machine just because third-party code can be dangerous, then yes, you can blame Microsoft for not taking control away from you.
by alanjay on 7/19/24, 8:17 PM
MS provided a kernel-level entry point that other OSes didn't need.
MS have an aggressive auto-update policy that is anti-best practise.
MS have a signed binary agreement that doesn't catch the things it is meant to.
by tamiral on 7/19/24, 5:50 PM
by omoikane on 7/19/24, 8:48 PM
https://news.ycombinator.com/item?id=41009740
Such a file will not have the right signature and checksum to be considered a valid executable. Either these were not checked, or whatever was doing the checking responded poorly and left the system in a state that's difficult to recover.
by Semaphor on 7/19/24, 9:12 PM
by aranelsurion on 7/19/24, 6:32 PM
Windows is the platform, CrowdStrike makes a product on this platform and their users willingly install, accept all the security prompts and use it. Short of Apple-style locking users out of their own devices, there is little they can do here.
I'm not well-versed in Windows enough to be able to tell if they provide better ways and safe APIs to achieve what CrowdStrike does, but even if they did, there is no telling if CrowdStrike or anyone else would use that or not.
> but I feel that good OS should prevent a 3rd party app to cause such damage
It does? It also allows the owner of the machine to bypass those preventions, which is what CrowdStrike seem to require for their product to function.
I think the "OS should protect me from myself" is a very iPad-style expectation from computers. Personally I'm happy there are OSes that don't work this way.
> Would it happen on Linux?
$ modprobe crap-mod
I guess it would.
by aptgetrekt on 7/19/24, 11:09 PM
On Windows, software regularly mucks around in the kernel (device drivers, system level tools like wireshark, etc), therefore it is also necessary for security software like CrowdStrike to also muck in the kernel so it can monitor what all the other kernel level software is doing. As demonstrated today, anything that mucks in the kernel runs the risk of crashing the kernel.
In Linux, software doesn't even get that option. Nothing ever gets kernel access except the kernel itself. Root is not kernel access. The kernel still decides what root is able to do. Drivers that require that access are built into the kernel. Software that requires deeper access like Wireshark tells the kernel what to do (through system calls as root) and the kernel does it on that programs behalf. Therefore, the kernel knows everything that any program does on the system. With a trustworthy kernel, all that security software must do is instruct the kernel to monitor activity on it's behalf.
by aristofun on 7/19/24, 6:56 PM
Yes all platforms seen bad days and have their own issues.
But windows is different - most of its troubles come from human factor - low quality people making (or made 10 years ago) low quality decisions and every new iteration is just another layer of bad decisions aimed to cover the holes in previous layer.
You can see and feel it even un ui - there is no esthetics nor real usability and never was.
by greatgib on 7/20/24, 11:12 AM
Then you understand that it is not the core that crashed, but if there is any error, in any driver, the mandated behavior is to trigger a "BUGCHECK" in the same way that you would just do a printf(error) usually...
by ryandrake on 7/19/24, 10:10 PM
by Am4TIfIsER0ppos on 7/19/24, 9:10 PM
by ChrisArchitect on 7/19/24, 1:11 PM
by aredox on 7/19/24, 5:00 PM
by 1vuio0pswjnm7 on 7/20/24, 4:33 AM
Windows is closed source for the vast majority of people who use it. No one oustide Microsoft, not even those who may have signed NDAs and can read some of the code, is free to edit the Windows source and recompile. If a Windows user wants to prevent something like this outage from happening, he cannot obtain the Windows source and make changes to prevent it. Instead he is encouraged (perhaps compelled) to let Microsoft remotely install and run new code any time it wants.
by yamumsahoe on 7/19/24, 10:46 PM
by middlefing on 7/19/24, 11:15 AM