> Why would an anti-malware program be allowed to install a driver automatically ... or ever for that matter?

Because malware that gets into a system will do just that -- install its own backdoor drivers -- and will then erect defense to protect itself from future updates or security actions. e.g. change the path that Windows Updater uses to download new updates, etc.

Having a kernel module that answers to CloudStrike makes it harder for that to happen, since CS has their own (non-malicious) backdoor to confirm that the rest of the stack is behaving as expected. And it's at the kernel level, so it has visibility into deeper processes that a user-space program might not (or that is easy to spoof).

Or, much more likely, the malware will use a memory access bug in an existing, poorly written kernel module (say, CrowdStrike?) to load itself at the kernel level without anyone knowing, perhaps then flashing an older version of the BIOS/EFI and nestle there, or finding it's way into a management interface. Hell, it might even go ahead and install an existing buggy driver by itself it's not already there.

All of these invasive techniques end up making security even worse in the long term. Forget malware - there's freely available cheating software that does this. You can play around with it, it still works.

Maybe I am in the minority, but it always puzzled me that anybody in IT would think a mega-priviledged piece of software that looks into all files was a good idea.

If there is any place that historically was exploited more than all other things it was broken parsers. Congratulations if such an exploited file is now read by your AV-software it now sits now at a position where it is allowed (expected) to read all files and it would not surprise me if it could write them as well.

And you just doubled the number of places in which things can go wrong. Your system/software that reads a PNG image might do everything right, but do you know how well your AV-software parses PNGs?

This is just an example, but the question we really should ask ourselves is: why do we have systems where we expect malicous files to just show up in random places? The problem with IT security is not that people don't use AV software, it is that they run systems that are so broken by design that they are sprinkled on top.

This is like installing a sprinkler system in a house full of gasoline. Imagine gasoline everywhere including in some of the water piping — in the best case your sprinkler system reacts in time and kills the fire, in the worst case it sprays a combustive mix into it.

The solution is of course not to build houses filled with gasoline. Meanwhile AV-world wants to sell you ever more elaborate, AI-driven sprinkler systems. They are not the ones profiting from secure systems, just saying..

> but it always puzzled me that anybody in IT would think a mega-priviledged piece of software that looks into all files was a good idea.

Because otherwise, a piece of malware that installs itself at a "mega-privileged" level can easily make itself completely invisible to a scanner running as a low-priv user.

Heck, just placing itself in /root and hooking a few system calls would likely be enough to prevent a low-priv process from seeing it.

You're ignoring the parent's question of "why do we have systems where we expect malicous files to just show up in random places?", which I think is a good question. If a system is truly critical, you don't secure it by adding antivirus. You secure it by restricting access to it, and restricting what all software on the machine can do, such that it's difficult to attack in the first place. If your critical machines are immune to commodity malware, now you only have to worry about high-effort targeted attacks.

My point exactly. Antivirus is a cheap on top measure thst makes people feel they have done something, the actual safety of a system comes from preventing people and software from doing things they shouldn't do.

Why would you design a system where a piece of malware can "install itself" at a mega-priviledged position?

My argument was that this is the flaw, and everything else is just trying to put lipstick on a pig.

If you have a nightclub and you have problem controlling which people get in, the first idea would be to not have a thousand unguarded doors and to then recruit people that search the inside of your nightclub for people they think didn't pay.

You probably would think about reducing the numbers of doors and adding effective mechanisms to them that help you with your goals.

I am not saying we don't need software that checks files at the door, I say we need to reduce the number of doors leading directly to the nightclubs cash reserve.

I wonder why and how does security software read a PNG file. Sure it's not tough to parse a PNG file, but what does it look for exactly?

Some file formats allow data to be appended or even prepended to the expected file data and will just ignore the extra data. This has been used to create executables that happen to also be a valid image file.

I don't know about PNG, but I'm fairly sure JPEG works this way. You can concatenate a JPEG file to the end of an executable, and any JPEG parser will understand it fine, as it looks for a magic string before beginning to parse the JPEG.

A JPEG that has something prepended might raise an eyebrow. A JPEG that has something executable prepended should raise alarms.

Why make something like that executable in the first place? I like the Unix model where things that should be executable are marked so. I know bad parsers and format decoders can lead to executable exploits, but I've always felt uncomfortable with the windows .exe model. Also VBA in excel, word... I believe a better solution would be to have a minimal executable surface than invasive software.

Vendors are allowed to install drivers , even via Windows update. Many vendors like HP, install functionality like telemetry as drivers to make it more difficult for the users to remove the software.

So next time you think you are doing a "clean install", you are likely just re-installing the same software that came with the machine.

It doesn't install the driver, it is the driver. As for the Linux version, it uses eBPF which has a sandbox designed to never crash the kernel. Windows does have something similar nowadays, but Crowdstrike's code probably predates it and was likely just rawdogging the kernel.

> Why would an anti-malware program be allowed to install a driver automatically ... or ever for that matter?

While the files are named XXX.SYS they are apparently not drivers. The issue is that a corrupted XXX.SYS was loaded by the already-installed driver which promptly crashes.

As I understand it was a definition update that caused a crash inside already installed driver.