[duped]

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. CrowdStrike can keep the behavior the same but adjust the parameters by shipping "channel" files that fill in the templates.

"Sensor content", including the templates, are a part of the normal test and release process and goes through testing/verification before being signed/shipped. Customers have control over rollouts and testing.

"Rapid Response Content" is deployed through a different channel that customers do not have control over. Crowdstrike shipped a broken channel file that passed validation but was not tested.

They are going to fix this by adding testing of "rapid response" content updates and support the same rollout logic they do for the driver itself.

(*) I'm using the word "script" here loosely. I don't know what these things are, but they sound like scripts.

---

In other words, they have scripts that would crash given garbage arguments. The validator is supposed to check this before they ship, but the validator screwed it up (why is this a part of release and not done at runtime? (!)). It appears they did not test it, they do not do canary deployments or support rollout of these changes, and everything broke.

Corrupting these channel files sounds like a promising way to attack CS, I wonder if anyone is going down that road.

[hello_moto]

> 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?

[duped]

How do we know it hasn't?

[hello_moto]

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

The group behind it will come out to the public.

[sudosysgen]

This would be the kind of vulnerability that would be worth millions of dollars and used for targeted attacks and/or by state actors. It could take years to uncover (like Pegasus, which took 5 years to be discovered) or never be uncovered at all.

[cjbprime]

Probably not, if you're implying remote code execution -- it was an out of bounds READ operation, not write, causing an immediate crash. Unlikely to be useful for anything other than taking systems offline (which can certainly be useful, but is not RCE).

[sudosysgen]

It was a read operation during bytecode template initialization, in a driver that reads userland memory. An out of bound read operation to load code in a driver that maps user memory can easily lead to code execution and privilege escalation: if the attacker finds a way to get the out of bound read into memory they control, they could cause the driver to load a manufactured template and inject bytecode.

It's not clear that this specific vulnerability is exploitable, but it's exactly the kind of vulnerability that could be exploited for code execution.

[WatchDog]

> Corrupting these channel files sounds like a promising way to attack CS, I wonder if anyone is going down that road.

You would have to get into the supply chain to do much damage.

Otherwise, you would somehow need access to the hosts running the agent.

If you a threat-actor that already has access to hosts running CS, at a scale that would make the news, why would you blow your access on trying to ruin CS's reputation further?

Perhaps if you are a vendor of a competing or adjacent product that deploys an agent, you could deliberately try and crash the CS agent, but you would be caught.