To be fair, kernel level access by third party software is kind of frowned upon in the Linux world. Ask any desktop Linux user how they feel about NVIDIA (the only third party kernel code an average Linux user will install) and their drivers randomly causing strange issues on their systems up to and including kernel panics compared to the experience on AMD where the driver is open and built into the kernel itself. For security software that needs low level visibility, there is eBPF, direct kernel level access isn’t needed (though I believe CrowdStrike uses it, and thay actually did CrowdStrike Debian and Rocky Linux systems some time back).
MacOS blocked the majority of kernel extensions a few years ago as well.
Windows is the only OS where it has been designed in a way where kernel level access is the rule rather than the exception. So design flaws are at least partially at fault here.
Crowdstrike released bad code into prod without giving it some hours of testing in local machines or whatever. Incredible fuckup, inimaginable. But, let’s not take blame out of Microsoft, if a driver is faulty the system should be resilient enough no to crap the bed on login. At least enough for IT to be able to remotely access the system and fix it. The manual work the IT world has had to do because it’s lost remote access to workstations is insane.
Same thing would happen on Linux if someone wrote a bad kernel module and integrated it into the OS. In fact, Crowdstrike did have a similar problem a few months ago on Linux.
I’m no fan of Microsoft, but this isn’t their fault.
That is true. The issue is that because there are so many permission escalation issues in windows, that many anti malware products must run as kernel drivers.
So why is this considered a crowdstrike issue and not a Microsoft fuckup?
Windows: exists
Crowdstrike: stabs
You: why would Microsoft stab themselves?
To be fair, kernel level access by third party software is kind of frowned upon in the Linux world. Ask any desktop Linux user how they feel about NVIDIA (the only third party kernel code an average Linux user will install) and their drivers randomly causing strange issues on their systems up to and including kernel panics compared to the experience on AMD where the driver is open and built into the kernel itself. For security software that needs low level visibility, there is eBPF, direct kernel level access isn’t needed (though I believe CrowdStrike uses it, and thay actually did CrowdStrike Debian and Rocky Linux systems some time back).
MacOS blocked the majority of kernel extensions a few years ago as well.
Windows is the only OS where it has been designed in a way where kernel level access is the rule rather than the exception. So design flaws are at least partially at fault here.
Windows: exists
Crowdstrike: exists
Windows: open belly, right here!
Crowdstrike: stabs
Crowdstrike released bad code into prod without giving it some hours of testing in local machines or whatever. Incredible fuckup, inimaginable. But, let’s not take blame out of Microsoft, if a driver is faulty the system should be resilient enough no to crap the bed on login. At least enough for IT to be able to remotely access the system and fix it. The manual work the IT world has had to do because it’s lost remote access to workstations is insane.
Same thing would happen on Linux if someone wrote a bad kernel module and integrated it into the OS. In fact, Crowdstrike did have a similar problem a few months ago on Linux.
I’m no fan of Microsoft, but this isn’t their fault.
An OS should not have to require a 3rd party driver for security.
Microsoft should be writing that driver as an OS component. Drivers should be restricted for taking to hardware.
I thought only people who subscribed to CrowdStrike’s services had that driver installed.
That is true. The issue is that because there are so many permission escalation issues in windows, that many anti malware products must run as kernel drivers.