CrowdStrike Official RCA is now out [pdf]

&gt; In summary, it was the confluence of these issues that resulted in a system crash: [...] the lack of a specific test for non-wildcard matching criteria in the 21st field.<p>I feel they focus a lot on their content validator lacking a check to catch this specific error (probably since that sounds like a more understandable oversight) when the more glaring issue is that they didn&#x27;t try actually running this template instance on even a single machine, which would&#x27;ve instantly revealed the issue.<p>Even for amateur software with no unit&#x2F;integration tests, the developer will still have typically ran it on their own machine to see it working. Here CrowdStrike seem to have been flying blind, just praying new template instances work if they pass the validation checks.<p>They do at least promise to &quot;ensure that every new Template Instance is tested&quot; further down.

It doesn&#x27;t even cover the barest of organisational root cause. How are they planning to do defense in depth and prevent any internal threat actor from wedging every machine in the world?

That&#x27;s a lot of words to say &quot;We did not test a file that gets ingested by a kernel level program, not even once&quot;<p>At no point did they deploy this file to a computer they owned and attempted to boot it. They purposely decided to deploy behavior to every computer they could without even once making sure it wouldn&#x27;t break from something stupid.<p>Are these people fucking nuts?<p>I do more testing than this and I might be incompetent. Also nothing I touch will kill millions of PCs. I get having pressure put on you from above, I get being encouraged to cut corners so some shithead can check off a box on his yearly review and make more money while stiffing you on your raise, I get making mistakes.<p>But like, fuck man, come on.

They should&#x27;ve read &quot;parse, not validate&quot;: <a href="https:&#x2F;&#x2F;lexi-lambda.github.io&#x2F;blog&#x2F;2019&#x2F;11&#x2F;05&#x2F;parse-don-t-validate&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lexi-lambda.github.io&#x2F;blog&#x2F;2019&#x2F;11&#x2F;05&#x2F;parse-don-t-va...</a>

A lot of mitigation actions but nothing to really stop it happening again: a fail safe system in their boot start driver. Bad programming and QA caused the issue, but bad design allowed it to happen

Add a new threat actor to the list, those pesky parameter counts actively trying to evade detection:<p><i>&quot;This parameter count mismatch evaded multiple layers of build validation and testing, as it was not discovered during the sensor release testing process, the Template Type (using a test Template Instance) stress testing or the first several successful deployments of IPC Template Instances in the field.&quot;</i><p>Curious that csagent.sys isn&#x27;t mentioned until last page, p. 12:<p><i>&quot;csagent.sys is CrowdStrike’s file system filter driver, a type of kernel driver that registers with components of the Windows operating system…&quot;</i>

Well I guess I should post the obligatory<p>&gt; Some people, when confronted with a problem, think<p>&gt; “I know, I’ll use regular expressions.”<p>&gt; Now they have two problems.

Cleaner link: <a href="https:&#x2F;&#x2F;www.crowdstrike.com&#x2F;blog&#x2F;channel-file-291-rca-available&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.crowdstrike.com&#x2F;blog&#x2F;channel-file-291-rca-availa...</a>

Note: this was distributed to their customers today

Is it just me or does it seem like this change simply wasn&#x27;t tested beyond a simple unit test?

kinda sounds like this was a regex bug?<p>&gt; The selection of data in the channel file was done manually and included a regex wildcard matching criterion in the 21st field for all Template Instances, meaning that execution of these tests during development and release builds did not expose the latent out-of-bounds read in the Content Interpreter when provided with 20 rather than 21 inputs.