This is an unpopular opinion, and I get why – people crave a scapegoat. CrowdStrike undeniably pushed a faulty update demanding a low-level fix (booting into recovery). However, this incident lays bare the fragility of corporate IT, particularly for companies entrusted with vast amounts of sensitive personal information.
Robust disaster recovery plans, including automated processes to remotely reboot and remediate thousands of machines, aren’t revolutionary. They’re basic hygiene, especially when considering the potential consequences of a breach. Yet, this incident highlights a systemic failure across many organizations. While CrowdStrike erred, the real culprit is a culture of shortcuts and misplaced priorities within corporate IT.
Too often, companies throw millions at vendor contracts, lured by flashy promises and neglecting the due diligence necessary to ensure those solutions truly fit their needs. This is exacerbated by a corporate culture where CEOs, vice presidents, and managers are often more easily swayed by vendor kickbacks, gifts, and lavish trips than by investing in innovative ideas with measurable outcomes.
This misguided approach not only results in bloated IT budgets but also leaves companies vulnerable to precisely the kind of disruptions caused by the CrowdStrike incident. When decision-makers prioritize personal gain over the long-term health and security of their IT infrastructure, it’s ultimately the customers and their data that suffer.
C++ is the problem. C++ is an unsafe language that should definitely not be used for kernel space code in 2024.
the virus definition is not written in c++. And even then, the problem was that the file was full of zeros.
Maybe I heard some bad information, but I thought the issue was caused by a null pointer exception in C/C++ code. If you have a link to a technical analysis of the issue I would be interested to read it.
They said it was a “logic error”. so i think it was more likely some divide by zero or something like that
No one does, it’s not public yet, if ever. This is close enough.
The real problem was, among others, lack of testing, regardless of the programming language used. Blaming C++ is dumb af. Put a chimpanzee behing the wheel of a Ferrari and you’ll still run into… problems.
I’ll reiterate, if it was a null pointer exception (I honestly don’t know that it was, but every comment I’ve made is based on that assumption, so let’s go with it for now) then I absolutely can blame C++, and the code author, and the code reviewer, and QA. Many links in the chain failed here.
C++ is not a memory safe language, and while it’s had massive improvements in that area in the last two decades, there are languages that make better guarantees about memory safety.
but it very probably was not a memory error. Rust isn’t magic. It probably could not have prevented this bug anyway.
Let’s rewrite everything in Rust. That’ll surely solve the world’s problems.
Thank you. Finally someone understands. Jokes aside though, I think we can acknowledge that C/C++ have caused decades of problems due to their lack of memory safety.