Crowdstrike failure - How? Why?

[BigT]

@markn_1

@BigT

I’m not all that knowledgeable in this sort of programming, but using Regex as your parser for important files does sound alarm bells in my head. For one thing, Regexes don’t return errors. ⁢

I’m not sure what you mean by that. A regex match will certainly tell you if the string doesn’t match the pattern. That’s the whole point of a regex match. Regex has limitations in the type of pattern it can match, but if the pattern you’re trying to match is of an appropriate type, using regex is perfectly fine. ⁢

Sure, it will tell you it didn’t match. But it will not error. Even if you give it an invalid input, it will still do its thing.

Though I am now starting to think this may be irrelevant. It made sense to me when I wrote that.

[markn_1]

I don’t want to beat a dead horse, but I don’t understand what you mean by “invalid input”. Do you mean a malformed regular expression? Most regex libraries will indeed report an error when you compile such a pattern (eg. regcomp() returns nonzero; pcre_compile() returns NULL, etc). Or do you mean an invalid string to match? An invalid string is the same as a non-matching string, so the failure to match will show that.

[LSLGuy]

Any parser, regex or otherwise, has to deal somehow with malformed input. Absent input just being a corner case of malformed.

For a roll-your-own (“RYO”) parser, the granularity of error reporting is up to the creativity and diligence of the author. The number and severity of unhandled cases is also up to that author. As is whether the parser reports a coherent error or simply crashes in the various unthought-of cases.

Assuming the config file design wasn’t too brain damaged, I’d tend to believe the number of cases where malformed input caused a crash in the parser is far fewer w a regex than a RYO.

Now if the code just downstream simply assumed the config file is always present, is always well-formed, and the parse always succeeds resulting in the usual filled-in result object or array or whatever … well those are some really dangerous assumptions.

[Francis_Vaughan]

Regular expression is a specific type of grammar. It isn’t just a text matching system. There is nothing about the security rules using a regular expression speciation that precludes any amount of error checking.

Indeed use of a regular expression definition should promote safety as it specifically limits how the system can be defined into statically checkable rules, rather than arbitrary code, yet provides a significant amount of power in what can be defined.

The flaw in not testing the 21st parameter of a definition interface is a different matter.