Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Preliminary Post Incident Review

crowdstrike.com

Post reply on HN
Print view View original

81–90 of 227 posts

Re: Preliminary Post Incident Review

#81

Post by duped »

hello_moto wrote: post #75
duped wrote: post #57

Here is my summary with the marketing bullshit ripped out. Falcon configuration is shipped with both direct driver updates ("sensor content"), and out of band ("rapid response content"). "Sensor Content" are scripts (*) that ship with the driver. "Rapid response content" are data that can be delivered dynamically. One way that "Rapid Response Content" is implemented is with templated "Sensor Content" scripts. CrowdSt…

> Corrupting these channel files sounds like a promising way to attack CS, I wonder if anyone is going down that road. Would have happened long time ago if it was that easy no?

How do we know it hasn't?

Re: Preliminary Post Incident Review

#82

Post by denton-scratch »

Narretz wrote: post #40
Ukv wrote: post #28

A summary, to my understanding: * Their software reads config files to determine which behavior to monitor/block * A "problematic" config file made it through automatic validation checks "due to a bug in the Content Validator" * Further testing of the file was skipped because of "trust in the checks performed in the Content Validator" and successful tests of previous versions * The config file causes their software t…

* Further testing of the file was skipped because of "trust in the checks performed in the Content Validator" and successful tests of previous versions that's crazy. How costly can it be to test the file fully in a CI job? I fail to see how this wasn't implemented already.

> How costly can it be to test the file fully in a CI job?

It didn't need a CI job. It just needed one person to actually boot and run a Windows instance with the Crowdstrike software installed: a smoke test.

TFA is mostly an irrelevent discourse on the product architecture, stuffed with proprietary Crowdstrike jargon, with about a couple of paragraphs dedicated to the actual problem; and they don't mention the non-existence of a smoke test.

To me, TFA is not a signal that Crowdstrike has a plan to remediate the problem, yet.

Re: Preliminary Post Incident Review

#83

Post by [deleted] »

Narretz wrote: post #40
Ukv wrote: post #28

A summary, to my understanding: * Their software reads config files to determine which behavior to monitor/block * A "problematic" config file made it through automatic validation checks "due to a bug in the Content Validator" * Further testing of the file was skipped because of "trust in the checks performed in the Content Validator" and successful tests of previous versions * The config file causes their software t…

* Further testing of the file was skipped because of "trust in the checks performed in the Content Validator" and successful tests of previous versions that's crazy. How costly can it be to test the file fully in a CI job? I fail to see how this wasn't implemented already.

[deleted]

Re: Preliminary Post Incident Review

#84

Post by cataflam »

lopkeny12ko wrote: post #11

[flagged]

Not really, that thread showed only superficial knowledge and analysis, far from hitting the nail on the head, for anyone used to assembly/reverse engineering. Then goes on to make provably wrong assumptions and comments. There is actually a null check (2 even!) just before trying the memory access. The root cause is likely trying to access an address that's coming from some uninitialized or wrongly initialized or non-deterministically initialized array.

What it did well was explaining the basics nicely for a wide audience who knows nothing about a crash dump or invalid memory access, which I guess made the post popular. Good enough for a general public explanation, but doesn't pass the bar for an actual technical one to any useful degree.

I humbly concur with Tavis' take

https://x.com/taviso/status/1814762302337654829

Here are some others for more technically correct details: - https://x.com/patrickwardle/status/1814343502886477857 - https://x.com/tweetingjose/status/1814785062266937588

Re: Preliminary Post Incident Review

#85

Post by hello_moto »

mc32 wrote: post #80
hello_moto wrote: post #76

Earlier quoted context omitted.

You're saying there exist a complex software system without a bug despite following best practices to the dot and certified + compliant?

No, but their release process should catch major bugs such as this. After internal QA, you release to small internal dev team, then to select members of other depts willing to dog-food it, then limited external partners then GA? Or something like that so that you have multiple opportunities to catch weird software/hardware interactions before bringing down business critical systems for major and small companies aroun…

> After internal QA, you release to small internal dev team, then to select members of other depts willing to dog-food it, then limited external partners then GA

What about AV definition update for 0day swimming in the tubes right now?

Re: Preliminary Post Incident Review

#86

Post by hello_moto »

duped wrote: post #81
hello_moto wrote: post #75

Earlier quoted context omitted.

> Corrupting these channel files sounds like a promising way to attack CS, I wonder if anyone is going down that road. Would have happened long time ago if it was that easy no?

How do we know it hasn't?

If it happened, the industry would have known by now.

The group behind it will come out to the public.

Re: Preliminary Post Incident Review

#89

Post by l00tr »

cataflam wrote: post #87

Besides missing the actual testing (!), the staged rollout (!), looks like they also weren't fuzzing this kernel driver that routinely takes instant worldwide updates. Oops.

check their developer github, "i write kernel-safe bytecode interpreters" :D, [link redacted]

Re: Preliminary Post Incident Review

#90

Post by aeyes »

Do you see how they only talk about technical changes to prevent this from happening again?

To me this was a complete failure on the process and review side. If something so blatantly obvious can slip through, how could ever I trust them to prevent an insider from shipping a backdoor?

They are auto updating code with the highest privileges on millions of machines. I'd expect their processes to be much much more cautious.

Post reply on HN