I doubt it. Few people are volunteering their time reading pull requests of random repos. It probably went fast from pull request to deployment, so there would be no time for anyone external to read.
The only thing open source would’ve done is to give us a faster explanation of why it happened after the fact.
Considering this is a cybersecurity product that requires installing a kernel mode driver on mission-critical hardware, I guarantee at least a few people would have been interested in looking at the source if they had the opportunity. Or tried to convince their employers purchasing the software to pay for a third-party audit.
The update that broke everything only pushed data, not code. The bug was extant in the software before the update, likely for years. Can I say for sure that a few extra eyes on the code would have found the problem ahead of time? No, of course not. But it couldn’t have hurt.
The update that broke everything only pushed data, not code. The bug was extant in the software before the update, likely for years.
A terrifyingly large number of critical issues come to light like this. The code has been broken since the first release, but nobody noticed until a certain edge-case occurs.
Exactly. Even worse, a bug like this isn’t just a crash waiting to happen. It’s also a massive security hole.
If an incompetently written file can crash the system, there’s a decent chance that a maliciously crafted file could have allowed the complete takeover of it. Memory safety bugs, especially in kernel code, are very serious.
A lack of validation would have been a glaring red flag to any outsider looking at the code, but it’s exactly the kind of thing someone who’s worked on the software forever could easily overlook. It’s so, so easy to lose sight of the forest for the trees.
Or during, and with open source it could have been possible for independent fixes to have been created as people figured out through trial and error. Additionally, something like this would have cost Crowdstrike a ton of trust, and we would see forks of their code to prevent this from happening again, and now have multiple options. As it stands, we have nothing but promises that something like this won’t happen again, and no control over it without abandoning the entire product.
Even if a fix was discovered quickly it wouldn’t prevent the problem that it must be manually fixed on each computer. In this case a fix was discovered quickly even without access to source code.
Just having more eyes on the source code won’t do much. To discover errors like these the program must be properly tested on actual devices. This part obviously went wrong on Crowdstrike’s side. Making the code open source won’t necessarily fix this. People aren’t going to voluntarily try every cutting edge patch on their devices before it goes live.
I also doubt any of the forks would get much traction. IT departments aren’t going to jump to the next random fork, especially when the code has kernel access. If we can’t trust Crowdstrike, how can we trust new randos?
To my understanding, the driver was apparently attempting to process update files without verifying the content first (in this case a file containing all zeroes), so this issue would have likely been visible long before the catastrophe actually happened.
Yes. Security through obscurity is an illusion. ClamAV is a well known and high performance open source AV solution.
Edit: Here is the CWE entry on the topic in case anybody wants to read some more details as to how and why obscurity is not a valid approach to security.
Strictly speaking, it’s not anti-virus software. It’s not designed to prevent malicious software from running or remove it. It’s just monitoring for behavior that looks malicious so it can notify the system administrator and they can take manual action.
Most of the actual proprietary value, ironically enough, is in data files like the one that broke it. Those specify the patterns of behavior that the software is looking for. The software itself just reads those files and looks at the things they tell it to. But that’s where the bug was: in the code that reads the files.
Any software running in kernel mode needs to be designed very carefully, because any error will crash the entire system.
The software is risky because it needs to run in kernel mode to monitor the entire system, but it also needs to run unsigned code to be up to date with new threats as they are discovered.
The software should have been designed to verify that the files are valid, before running them. Whatever sanity checks they might have done on the files, it clearly wasn’t thorough enough.
From my reading, this wasn’t an unforeseeable bug, but a known risk that was not properly designed around.
If the security of your algorithm depends on the algorithm itself being secret, then it’s not safe to distribute the software only in binary form either.
Anti-virus companies–when they do it right–have tightly controlled air-gapped systems that they use to load viruses and test countermeasures. It takes a lot of staff to keep those systems maintained before we even talk about the programming involved, plus making sure some idiot doesn’t inadvertently connect those machines to the main building WiFi.
Well it isn’t actually a confirmed case. Ruiu, the original person reporting the issue wasn’t sure exactly what the surface area of attack was at the start. Ruiu Dragos, who is a security researcher believed it infected via speakers.
Eventually Errata CEO, Robert Graham, said that if he spent a year, he could build malware that did the same and that it was ‘really, really easy’
Eventually, Ruiu noticed that the initial stage of infection was from one of his USB sticks.
The speakers part comes in that he found that the packets transmitted between badBIOS infected machines stopped if he disconnected the internal speaker and microphone.
Meaning, that sure, badBIOS may communicate data with each other via speakers but that it has never been proven that it could actually infect another machine via speakers. However, that hasn’t stopped articles from conflating things.
If the Falcon driver was open source, someone might have actually caught the bug ahead of time.
I doubt it. Few people are volunteering their time reading pull requests of random repos. It probably went fast from pull request to deployment, so there would be no time for anyone external to read.
The only thing open source would’ve done is to give us a faster explanation of why it happened after the fact.
Considering this is a cybersecurity product that requires installing a kernel mode driver on mission-critical hardware, I guarantee at least a few people would have been interested in looking at the source if they had the opportunity. Or tried to convince their employers purchasing the software to pay for a third-party audit.
The update that broke everything only pushed data, not code. The bug was extant in the software before the update, likely for years. Can I say for sure that a few extra eyes on the code would have found the problem ahead of time? No, of course not. But it couldn’t have hurt.
A terrifyingly large number of critical issues come to light like this. The code has been broken since the first release, but nobody noticed until a certain edge-case occurs.
Exactly. Even worse, a bug like this isn’t just a crash waiting to happen. It’s also a massive security hole.
If an incompetently written file can crash the system, there’s a decent chance that a maliciously crafted file could have allowed the complete takeover of it. Memory safety bugs, especially in kernel code, are very serious.
A lack of validation would have been a glaring red flag to any outsider looking at the code, but it’s exactly the kind of thing someone who’s worked on the software forever could easily overlook. It’s so, so easy to lose sight of the forest for the trees.
Or during, and with open source it could have been possible for independent fixes to have been created as people figured out through trial and error. Additionally, something like this would have cost Crowdstrike a ton of trust, and we would see forks of their code to prevent this from happening again, and now have multiple options. As it stands, we have nothing but promises that something like this won’t happen again, and no control over it without abandoning the entire product.
Even if a fix was discovered quickly it wouldn’t prevent the problem that it must be manually fixed on each computer. In this case a fix was discovered quickly even without access to source code.
Just having more eyes on the source code won’t do much. To discover errors like these the program must be properly tested on actual devices. This part obviously went wrong on Crowdstrike’s side. Making the code open source won’t necessarily fix this. People aren’t going to voluntarily try every cutting edge patch on their devices before it goes live.
I also doubt any of the forks would get much traction. IT departments aren’t going to jump to the next random fork, especially when the code has kernel access. If we can’t trust Crowdstrike, how can we trust new randos?
To my understanding, the driver was apparently attempting to process update files without verifying the content first (in this case a file containing all zeroes), so this issue would have likely been visible long before the catastrophe actually happened.
Can you have open source anti virus software?
Yes. Security through obscurity is an illusion. ClamAV is a well known and high performance open source AV solution.
Edit: Here is the CWE entry on the topic in case anybody wants to read some more details as to how and why obscurity is not a valid approach to security.
Strictly speaking, it’s not anti-virus software. It’s not designed to prevent malicious software from running or remove it. It’s just monitoring for behavior that looks malicious so it can notify the system administrator and they can take manual action.
Most of the actual proprietary value, ironically enough, is in data files like the one that broke it. Those specify the patterns of behavior that the software is looking for. The software itself just reads those files and looks at the things they tell it to. But that’s where the bug was: in the code that reads the files.
I wouldn’t call it a bug.
Any software running in kernel mode needs to be designed very carefully, because any error will crash the entire system.
The software is risky because it needs to run in kernel mode to monitor the entire system, but it also needs to run unsigned code to be up to date with new threats as they are discovered.
The software should have been designed to verify that the files are valid, before running them. Whatever sanity checks they might have done on the files, it clearly wasn’t thorough enough.
From my reading, this wasn’t an unforeseeable bug, but a known risk that was not properly designed around.
Bet they use it to spy on workers looking for “slacker behavior”.
It’s installed mainly on servers which is why it broke everything on Friday.
It’s still run on pcs, at least is in mine.
If the security of your algorithm depends on the algorithm itself being secret, then it’s not safe to distribute the software only in binary form either.
Yes. CalmAV comes to mind. “Security by obscurity” is no security.
Not easily.
Anti-virus companies–when they do it right–have tightly controlled air-gapped systems that they use to load viruses and test countermeasures. It takes a lot of staff to keep those systems maintained before we even talk about the programming involved, plus making sure some idiot doesn’t inadvertently connect those machines to the main building WiFi.
There was at least one confirmed case of a virus spreading through speakers and microphones. What “air-gapped” means is pretty extreme.
If it’s possible at all, it’d have to be through significant donations or public funding. A volunteer effort isn’t going to cut it.
Well it isn’t actually a confirmed case. Ruiu, the original person reporting the issue wasn’t sure exactly what the surface area of attack was at the start. Ruiu Dragos, who is a security researcher believed it infected via speakers.
Eventually Errata CEO, Robert Graham, said that if he spent a year, he could build malware that did the same and that it was ‘really, really easy’
Eventually, Ruiu noticed that the initial stage of infection was from one of his USB sticks.
The speakers part comes in that he found that the packets transmitted between badBIOS infected machines stopped if he disconnected the internal speaker and microphone.
Meaning, that sure, badBIOS may communicate data with each other via speakers but that it has never been proven that it could actually infect another machine via speakers. However, that hasn’t stopped articles from conflating things.
Article doesn’t explain how it even coupd spread at all.
deleted by creator
Expected behavior: The file is not composed of null bytes.
Actual behavior; The file is composed entirely of null bytes.