It's because you (like me) aren't quite as paranoid as security people are. Personally I couldn't sleep at night if I was security people.
It's really a matter of context. Security people tend to only be involved when things are already nefarious where as boring old normal people like us see get to see the mundane everyday mistakes so not just the nefarious bits.
I'm a security people. I can say with confidence that a tiny, tiny, tiny, tiny fraction of these security issues are deliberate. Almost all of them are just dumb mistakes because making good software is really hard and really, really expensive and there is no market incentive to make good software. You don't need to get hired at the safe factory to build an elaborate back door into the production line if safes are actually just cardboard boxes, you know?
It's possible the backdoor is deliberate, I have no idea in this particular case, but the more likely situation, absent more information, is that someone who is earning a middling wage just added the "feature" and didn't think about the security implications because no one cares about computer security.
> It's because you (like me) aren't quite as paranoid as security people are.
I work heavily with security-conscious clients where vulnerabilities would be catastrophic. And we are talking high profile clients that are juicy target for attacks.
My experience is still that the vast majority of vulnerabilities are accidental rather than due to malice.
And when I say “vast”, I mean the so heavily slanted in favour of “unintended” that it’s not even comparable.
> It's really a matter of context. Security people tend to only be involved when things are already nefarious
I’m guessing you’ve not worked with many “security people”?
You’d be surprised how much of their day-to-day is mundane.
Oh i've worked with plenty. Maybe they knew more than they let on but they were (and are) convinced that every little belch is a full on attack.
I know their day to day is just as mundane as the rest of ours it's their "Step 1" approach that i've seen to be entirely different. I assume it's probably a software bug, they assume it's an exploit.
> I assume it's probably a software bug, they assume it's an exploit.
They're not mutually exclusive.
I suspect you and the security team are arguing the same thing but with different terminology.
When vulnerabilities (which, in the vast majority of cases, are accidental) are published, or when static analysis tools review code, you'll get a description and a severity score. That description will broadly describe how, if possible, that vulnerability can be exploited.
Working for an in-house security team basically just means you're a risk assessor. And the way you assess risks is to look at the potential consequences of those risks. Which means looking at how bugs can be exploited.
But none of this means those vulnerabilities were placed in the code intentionally and with malice. It just means that someone else who is malicious could, theoretically, exploit those vulnerabilities. And if the risk of that is greater than the risk appetite of the business (as will typically be the case), then they'll feedback to you that there is an exploitable vulnerability that you need to patch.
The main reason I assumed you didn't is because you linked to Hanlon's Razor and explained it in a way that made it seem like you didn't think the other person knew.
I think it's true to some extent that a lot of the backdoors really are just stupidity, like debugging tools put into prod for convenience. Rather than suggesting that it is genuine malice, maybe the right thing to say is that for security, it doesn't matter whether or not it is malice for most purposes. If it did, it would give more incentive to do as much as possible to disguise malicious backdoors as mistakes.
Maybe it's time to take a closer look at reality and correct this meme, which might casually blur the issue and deflect responsibility?
Looking at the IT security landscape we see every layer, every product category if not every product itself riddled with issues at one point or another. At the same time the incentives to put those security issues in are huge, and we know attackers work systematic, creative and persistent to introduce those weak points.
Security is hard and many bugs certainly happen due to mistakes, but I wouldn't assume that all of those security mishaps stem from an endless series of blunders from "stupid" programmers.
So I would go with “Never attribute to ignorance that which is adequately explained by malice.”
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.