[hatsunearu]

I'm not a big expert but honestly this read like a bunch of garbage.

> Although Channel Files end with the SYS extension, they are not kernel drivers.

OK, but I'm pretty sure usermode software can't cause a BSOD. Clearly something running in kernel mode ate shit and that brought the system down. Just because a channel file not in kernel mode ate shit doesn't mean your kernel mode software isn't culpable. This just seems like a sleezy dodge.

[gjm11]

It doesn't read to me as trying to dodge anything. They aren't saying "they're not kernel drivers, so everything is OK", they're saying "seeing the .sys on the filenames, you might think they're kernel drivers, but as it happens they're something else".

(Maybe there's some subtext that I'm missing, but I don't see how saying "these aren't kernel drivers" makes them look any better, and I do see why they might say it to be informative, so it looks like to me like they're doing the latter.)

[hatsunearu]

> It doesn't read to me as trying to dodge anything.

It absolutely reads like this. They are getting blasted online for shipping kernel mode driver updates without proper QA and release engineering. Which just from face value just seems like some insano style engineering. They are saying "it's not actually a kernel mode value" to deflect blame.

I mean, I really don't understand why they would make this statement otherwise. If they are innocently just trying to say "this is just a channel file", there are other ways to say this, and it really isn't relevant enough to underline and emphasize.

[bostik]

Friend does incident response and Windows forensics, and pointed something (in retrospect) rather obvious out yesterday: the instructions for cleaning up simply told people to "delete .SYS files according to this wildcard". No additional context.

That caught his eye, because to him it sounded like madness. Apparently deleting random driver files is a fairly well known way to screw a Windows system up even more than it already was.

This statement from CS must have gone through legal and PR review, so we have to assume every word and statement has been carefully vetted from a cover-your-backside perspective. It is light on information content, but there must be reason for them to so forcefully telegraph that the files being deployed (and removed) are not themselves drivers.

[dizhn]

They said to delete a single specific file. Did what you're saying happen before that or something?

[bostik]

The original instructions were "delete [something]00291-*.sys"

[gjm11]

They're getting blasted for causing a massive worldwide outage due to what is clearly inadequate quality control. I don't see why this is any better if it's "pushed a kernel-mode driver update with bugs in it" than if it's "released a product with buggy kernel-mode stuff that can be made to crash by an innocuous-looking data file, and then pushed a data file that made it crash". Same result either way. Same demonstration of inadequate quality control either way.

I think the story they're telling now, which so far as I know is the truth, looks worse for them, because it requires them to have screwed up their QC twice. Once when they made a product that do such bad things, and once when they pushed the data file to millions of PCs without checking what it did.

So I still don't see how "this particular file happens not to be kernel-mode code" makes them look any better, and therefore I don't see why they'd be saying it "to deflect blame". It doesn't deflect blame; they look just as bad either way.

[mynameisvlad]

You may understand it that way, but you also have a much deeper knowledge of this than the targeted audience of the RCA.

Make no mistake, this RCA was not published for technical folks. The only reason it’s even published is to make their customers feel more secure. You and I are not their customers; high level management and executives are.

[SoftTalker]

The kernel driver reads the channel files. It choked on this one, and crashed.

[SAI_Peregrinus]

Which implies that any malware capable of replacing these channel files can crash their kernel driver. I wonder if there's a non-crashing way to exploit this & get kernel-space code execution.

[amiga386]

Any malware capable of modifying files under C:\Windows\System32 has no need to fiddle with these files because to have that capability means it already got the keys to the kingdom and could wreck the system in a billion different ways.

See "It rather involved being on the other side of this airtight hatchway" https://devblogs.microsoft.com/oldnewthing/20200420-00/?p=10...

[SAI_Peregrinus]

The directory they're stored in needs Administrator access, but the kernel runs with SYSTEM level permissions. Administrator is an account, SYSTEM is a security principal. SYSTEM level processes can access domain servers in the context of the computer's domain account, while Administrators can't do so unless they provide explicit credentials (or share a password with an Administrator account on the domain). So this could be used as a way to elevate access from local Administrator up to whatever that computer can do on a connected domain server!

[SoftTalker]

And yet the cleanup instructions were for the user to delete a file in that directory. That requires booting into safe mode, but if any random user is able to do that, kiss your systems goodbye, a good social engineer (or disgruntled employee) will own any desktop in your organization if he wants to.

[amiga386]

The point is, malware can't get into that directory without user consent. Having physical access to the machine, rebooting into safe mode and running commands is a stonking big user consent.

I can pwn my own desktop, yes, all I have to do is say "run as administrator". But the point of the security boundary is to make it impossible for software to get these privileges without me actively giving it to them.

If you're shifting the goalposts and imagining the computer does not belong to me, but to an organisation that I'm a mere employee of, they'll be using AD Group Policy to control what I can and can't do, and Bitlocker to encrypt the boot drive. I cannot boot into safe mode without having the tech support department give me a special code to unlock the computer. Again, that's how you get on the other side of the airtight hatch.

[naib0930]

In my organizations any user couldn't do it, we have to manually touch every computer and enter the bit locker key. We lost in the neighborhood of 14,000 end points, every single one needs touched. My team of 10 did about 800 in 5 hours. Pulling and entering the bitlocker key was what took the longest.

[joshka]

If you have write access a path like C:\Windows\System32\drivers\CrowdStrike\ (and I'd assume the parent directory), then you pretty much can crash the kernel many ways.

If you have the means to insert an AV config file update in between the config servers and the user's host then you probably can PWN the system pretty easily as well.

What this probably does mean is that Crowdstrike will be receiving some attention from hackers of both hat colors. Here's the bug bounty page ... https://hackerone.com/crowdstrike?type=team

[numbsafari]

I can guarantee you that you aren't the only one thinking this right now.

[ytch]

IIRC, there were some security software exploits, that trigger RCE (or DoS) of the scanning engine by malicious file?

[teeray]

The kernel driver is an interpreter that executed an HCF instruction from the channel file.

[hatsunearu]

That's what I thought. So saying "it's not a kernel mode driver" is technically true, but I don't need to explain why it's a bunch of nonsense to try to damage control their incompetence.

[epcoa]

No idea why you’re getting downvoted. A configuration file for code that runs in kernel space is usually effectively kernel code (it certainly was in this case) - obviously there are formal methods to allow kernel code to be configured in a “safe” fashion, but it’s obvious that’s not going on here.