|
|
|
|
|
|
by UweSchmidt
20 days ago
|
|
|
It's usually not possible to prove that something was put in deliberately and maliciously, so that puts the bar very high. We know it for sure in some of the supply chain attacks, and should assume that other kinds of bugs are being introduced by malicious actors across the board, rather than to risk downplaying the issues to "just blunders". |
|
|
1. You can generally get a feel for the intent by the developers reputation.
2. Look at the code that changed as part of the same commits. Eg was the vulnerable code included as part of the same commits as an unrelated change elsewhere in the codebase? If the latter then that’s hugely suspicious.
3. How is that vulnerability encoded? Eg is a bug parsing logic that was discovered via fuzzing? Or is it obfuscated code? Clearly the latter demonstrates intent.
4. What’s the nature of the vulnerability? Is it simply a dumb unhandled bounds or allocation error in C? Or is there an entire path of code that opens network ports? The latter also demonstrates intent.
5. How did the authors behind the vulnerable code react to the big report? Did they rush a patch out? Write more robust tests? Work with the community? Was there any transparency? Or was the issue quietly brushed over? This is least reliable indicator but it does demonstrate trustworthiness.
With these and other indicators you can build a body of evidence that can make an argument for or against a particular vulnerability being malicious. And while I do agree that in some cases it isn’t going to be clear cut, in most cases the evidence, or lack of, will be enough to justify an opinion.
The key part of my earlier statement being “beyond reasonable doubt”. Ie I’m not talking about a mathematical proof here.