5 ms·

I feel Windows is wrongly blamed here it's just an OS. If you rely on your applications to be available you should have disaster recovery plans for scenarios l

I feel Windows is wrongly blamed here it's just an OS. If you rely on your applications to be available you should have disaster recovery plans for scenarios like this.

darby_nine 2y ago
Windows is also the platform where this sort of spyware has been normalized for decades as best practice.
- remram 2y ago
  There are similar products for Linux. My organization runs Cortex XDR, it has a kernel module. Had a few calls with them to figure out its features and how it would impact the systems. They didn't even know.
  - darby_nine 2y ago
    Fair enough.
evilduck 2y ago
Their disaster recovery plans include the same faults that brought them down this time, guaranteed.
mbreese 2y ago
A little yes, a little no. Was this problem caused by Microsoft? No. Why does this tool exist and must be installed on servers? Well, Windows OS design definitely plays a role here. Why does this software run in a critical path that can cause the machine to BSOD? This is where the OS is a problem. If it is fragile enough that a bad service like this can cause it to crash in an unfixable state (without manual intervention), that’s on Windows.
- timr 2y ago
  > Why does this tool exist and must be installed on servers? Fads, laziness, and lack of forethought. This tool didn't exist a few years ago. Nobody stopped IT departments worldwide and said "hey, maybe you shouldn't be auto-rolling critical software updates without testing, let alone doing this via a third-party tool with dubious checks." This could have happened on any OS. Auto deployment is the root problem.
- vbezhenar 2y ago
  In this very thread there was report of a Debian Linux fleet being kernel crashed in exactly the same scenario by exactly the same malware few months ago. So the only blame Windows can take is its widespread usage, compared to Debian.
  - arccy 2y ago
    there's an eBPF mode for linux which is safe(r) so windows can still be blamed for not providing a relatively safe way of doing this.
    - noisem4ker 2y ago
      Windows supports eBPF too.
    - vbezhenar 2y ago
      https://access.redhat.com/solutions/7068083 https://access.redhat.com/solutions/7068083 Kernel panic observed after booting 5.14.0-427.13.1.el9_4.x86_64 by falcon-sensor process. eBPF program causes kernel panic on kernels 5.14.0-410+ . Apparently not safe enough for CrowdStrike.
  - mbreese 2y ago
    Why the whataboutism? Yes, the Linux device driver has many of the same issues (monolithic drivers running in kernel space/memory). I’m not sure what the mitigations were in that case, but I’d be interested to know. But we both know this isn’t the only model (and have commented as such in the thread). MacOS has been moving away from this risk for years, largely to the annoyance of these enterprise security companies. The vendor that was used by an old employer blamed Apple on their own inability to migrate their buggy EDM program to the new version of macOS. So much so that our company refused to upgrade for over 6 months and then it was begrudgingly allowed.
- simiones 2y ago
  A tool that has full control of the OS (which is apparently required by such security software) fundamentally must have a way to crash the system, and continue to do so at every restart.
- jimbob45 2y ago
  Was this problem caused by Microsoft? No. This really should be a hell no. Perhaps Microsoft's greatest claim to fame is their enduring ability to quickly and decisively react to security breaches with updates. Their process is extremely public and hasn't significantly changed in decades. If your company can't work with Microsoft's process, your company is the problem. Every other software company in the last forty years has figured it out.
silisili 2y ago
I don't blame Windows, but do blame these systems for running Windows, if that makes sense. I imagined a lot of this ran on some custom or more obscure and hardened specialty system. One that would generally negate the need for antiviruses and such. (and obviously, no, not off the shelf Linux/BSD either)

I feel Windows is wrongly blamed here it's just an OS. If you rely on your applications to be available you should have disaster recovery plans for scenarios like this.

darby_nine 2y ago

Windows is also the platform where this sort of spyware has been normalized for decades as best practice.

remram 2y ago
There are similar products for Linux. My organization runs Cortex XDR, it has a kernel module. Had a few calls with them to figure out its features and how it would impact the systems. They didn't even know.
- darby_nine 2y ago
  Fair enough.

evilduck 2y ago

Their disaster recovery plans include the same faults that brought them down this time, guaranteed.

mbreese 2y ago

A little yes, a little no. Was this problem caused by Microsoft? No. Why does this tool exist and must be installed on servers? Well, Windows OS design definitely plays a role here. Why does this software run in a critical path that can cause the machine to BSOD? This is where the OS is a problem. If it is fragile enough that a bad service like this can cause it to crash in an unfixable state (without manual intervention), that’s on Windows.

timr 2y ago
> Why does this tool exist and must be installed on servers? Fads, laziness, and lack of forethought. This tool didn't exist a few years ago. Nobody stopped IT departments worldwide and said "hey, maybe you shouldn't be auto-rolling critical software updates without testing, let alone doing this via a third-party tool with dubious checks." This could have happened on any OS. Auto deployment is the root problem.
vbezhenar 2y ago
In this very thread there was report of a Debian Linux fleet being kernel crashed in exactly the same scenario by exactly the same malware few months ago. So the only blame Windows can take is its widespread usage, compared to Debian.
- arccy 2y ago
  there's an eBPF mode for linux which is safe(r) so windows can still be blamed for not providing a relatively safe way of doing this.
  - noisem4ker 2y ago
    Windows supports eBPF too.
  - vbezhenar 2y ago
    https://access.redhat.com/solutions/7068083 https://access.redhat.com/solutions/7068083 Kernel panic observed after booting 5.14.0-427.13.1.el9_4.x86_64 by falcon-sensor process. eBPF program causes kernel panic on kernels 5.14.0-410+ . Apparently not safe enough for CrowdStrike.
- mbreese 2y ago
  Why the whataboutism? Yes, the Linux device driver has many of the same issues (monolithic drivers running in kernel space/memory). I’m not sure what the mitigations were in that case, but I’d be interested to know. But we both know this isn’t the only model (and have commented as such in the thread). MacOS has been moving away from this risk for years, largely to the annoyance of these enterprise security companies. The vendor that was used by an old employer blamed Apple on their own inability to migrate their buggy EDM program to the new version of macOS. So much so that our company refused to upgrade for over 6 months and then it was begrudgingly allowed.
simiones 2y ago
A tool that has full control of the OS (which is apparently required by such security software) fundamentally must have a way to crash the system, and continue to do so at every restart.
jimbob45 2y ago
Was this problem caused by Microsoft? No. This really should be a hell no. Perhaps Microsoft's greatest claim to fame is their enduring ability to quickly and decisively react to security breaches with updates. Their process is extremely public and hasn't significantly changed in decades. If your company can't work with Microsoft's process, your company is the problem. Every other software company in the last forty years has figured it out.

silisili 2y ago

I don't blame Windows, but do blame these systems for running Windows, if that makes sense. I imagined a lot of this ran on some custom or more obscure and hardened specialty system. One that would generally negate the need for antiviruses and such. (and obviously, no, not off the shelf Linux/BSD either)