One of the first things the falcon driver does on boot is connect to the server, report some basic info, and start loading these data files, the "channel" files that Crowdstrike frequently updates.

The BSOD is because one of the data files that they previously pushed is horribly mangled, and their driver explodes about it. But if you get lucky, the driver can receive an update notification on boot, connect to the separate file server, and finish overwriting the broken file on disk before the rest of the driver (that would crash) has loaded the broken file

And they do all of that very early on boot. The justification being that you don't want the antivirus to start booting after a rootkit has already installed itself

WTF? Trust in the kernel should be Microsoft's responsibility and only theirs. Actually why is MS even allowing this crap code to run in their kernel? Isn't that a trust-destroying event?

Drivers have to run in the kernel in order to access hardware and other low-level system resources. That's how pretty much every mainstream OS works. For example, here's the guide for writing kernel-mode drivers in Linux: https://docs.kernel.org/driver-api/driver-model/overview.htm...

One might ask whether an anti-virus really needs to run inside the kernel, but the answer might reasonably be yes.

That is only the lazy solution.

It is also possible to access hardware or any other low-level system resources from unprivileged user code, if its process has been granted appropriate access rights by the kernel.

This second solution requires more work, but it is much more secure as the access can be limited to only the strictly-required resources and system crashes become impossible.

The extreme of this solution is a micro-kernel operating system, but there is no need for extremes. Even in a Windows or Linux system you can use this method. You can have a very reduced privileged code in a driver or kernel module, which does nothing except providing access to the permitted resources. Then anything like attempting to access not mapped memory would happen in user code and it would crash only the user process, not the entire computer system.

Yes, I'm no security expert by any means but I'd assume that e.g. a rootkit would be best defeated by a kernel driver.

So, this isn't really what's getting on my nerves here. Just how it auto updates and get pushed throughout the organizations without a smidge of quality assurance. Smaller businesses... Sure, I get it. They don't have the resources to set up infra for this, but those... airliners... and hospitals. WTF. I read some org thinking they might not even be able to provide anesthesia. Seriously. What.

Probably history and then some possible anti-trust litigation. As asking market leader not allow access to kernel like this would somehow be anti-trust violation...

I love how this is solution for security, while sounding like most insanely unsecure thing...

What, the auto-updating part? Obviously the client is verifying signatures (or using TLS with a client certificate, whatever), not just accepting whatever random file comes down the pipe.

Even then, how many affected machines there are? Tens of thousands, hundreds of thousands? Compromise these servers and even possible signing server and you have largest bot net or general compromise in history...

It is not unreasonable to think that this sort of software could get compromised.

A few more years and maybe they will add this newfangled super-innovative thing, invented by those esoteric academics at U of Haskell ... this new thing -- umm, what was it called -- try-catch perhaps.

I mean, this is every antivirus software. "Let's run some antivirus vendor's code on your system that opens literally every file on your system, regardless of how it got there."

Yeah, that's a great idea and not at all a huge attack vector.

You forgot the "... while in kernel mode".

this is a solution for "afterthought security" only.

Yes, that is as bad as it sounds.

> It auto-updates on boot? From the internet?

Apparently!

Probably has to do this early on in the boot process so as not to require a reboot after update because of Windows’s silly pessimistic file locking.

> because of Windows’s silly pessimistic file locking

To be honest I prefer that over the #nix way of doing things. In Windows, you have exactly one file any given path can refer to - in Linux or Mac, it may depend on which directory's inode is seen as the root node by your process (e.g. chroot or container), or whether mounts are at play, or a file/directory got deleted and replaced by something else.

Particularly the last scenario keeps tripping me every once in a while.

Does this mean a computer without internet access and with CrowdStrike would be unable to start up?

Surely a computer without internet would not have received the update?

But then would CrowdStrike stop the startup saying it requires network connectivity to initialize or something? Just wondering how invasive the app is

No, it'd boot up just fine without a network connection (as long as it didn't have this borked update).

How did it get broken then?

As in, does the OS require the internet so CrowdStrike can send telemetry data OR will it skip that step and just boot the OS like normal?

That would seem crazy. Maybe there is a crowdstrike onprem “master server” that is supposed to be available internally? Just spitballing, have no idea really