CrowdStrike update causes a Windows OS to crash and not even starting. It's definitely CrowdStrike's fault but I feel that good OS should prevent a 3rd party app to cause such damage. Can Windows take part of the blame for that outage? Would it happen on Linux?
Kinda. Yes. Apple moved away from deep kernel extensions years ago. They are no longer permitted on their latest releases.<p>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.<p>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."<p>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.<p>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.
> Would it happen on Linux?<p>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.<p>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.<p>So long story short only MacOS is resistant to this, because they've simply deprecated any third party kernel extensions/modules.
CS needs some hardcore permissions to scan items on a VERY low level. So they can essentially push out shit code to screw up any OS. Including Mac and Linux. Don't see how MS/Windows are to blame for someone not testing a content update before pushing to the whole damn world. They should at least push out to a subset of users before destroying everyone's Friday!
The code running in the kernel can do anything, including crashing the machine on boot. The only real way to prevent it is to disallow third-party kernel code.<p>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.
Yes.<p>MS provided a kernel-level entry point that other OSes didn't need.<p>MS have an aggressive auto-update policy that is anti-best practise.<p>MS have a signed binary agreement that doesn't catch the things it is meant to.
Crowdstrike and other tools that have this access is for them to update their agents so that in case they see a ransomware or attack pattern to push it out to as many devices as possible to stem the attack. Do you need all this crazy level of kernel access, probably not, I hope they will have some refactoring efforts in the future.
Windows might be partly responsible for handling corrupted files poorly. According to this other post, the offending file was filled with NULs:<p><a href="https://news.ycombinator.com/item?id=41009740">https://news.ycombinator.com/item?id=41009740</a><p>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.
You might be interested in this story about crowdsec killing people's Linux VMs 3 months ago: <a href="https://old.reddit.com/r/debian/comments/1c8db7l/linuximage61020_killed_all_my_debian_vms/" rel="nofollow">https://old.reddit.com/r/debian/comments/1c8db7l/linuximage6...</a>
Windows and BSODs maybe still are trigger words for me, but IMO they are not to blame.<p>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.<p>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.<p>> but I feel that good OS should prevent a 3rd party app to cause such damage<p>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.<p>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.<p>> Would it happen on Linux?<p>$ modprobe crap-mod<p>I guess it would.
As far as I understand, yes. It's kind of astounding to me that the world has self-inflicted what is essentially a cyber attack trying to protect a poorly architected OS from actual cyber attacks when a much better architected OS is known and running on nearly all the servers in the world.<p>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.<p>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.
How many more cases and years you need to finally admit that windows is a shitty platform?<p>Yes all platforms seen bad days and have their own issues.<p>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.<p>You can see and feel it even un ui - there is no esthetics nor real usability and never was.
A key moment about Windows for me is when I did read the windows official driver development guide and discovered that the real name of "bsod" is in fact "BUGCHECK".<p>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...
A big problem is that the Windows platform has normalized the idea of 3rd party software running at the kernel level, and end users allow it because it's so normal. They've also normalized the idea of 3rd party software (even games) requiring Admin access to run, which is not as bad but a similar threat. Software that routinely requires elevated privileges seems to be a bad idea.
HN commenters will defend the quality of Windows.<p>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.