Sometimes I wonder if it would be possible to estimate the probability of the presence of nasty vulnerabilities like this one on a software stack.
At one point, it seems that "everyone use this so it must be secure enough" replaced "we're a large company, did we spend enough time reviewing code of the open source stuff we use?".
It seems the Linus's quote "given enough eyeballs, all bugs are shallow", is not really true.
Imagine if a well funded agency like the NSA employed at least hundreds of full time developers whose job would be to sniff for those vulns. I'm pretty sure you could automate searching for those vulns, and that only the NSA has such tool.
> It seems the Linus's quote "given enough eyeballs, all bugs are shallow", is not really true.
Well that's the issue isn't it. Very few have read the log4j code, even though thousands of developers have incorporated it into they projects. Right now all eyes are on log4j and the bugs a showing up quicker than the log4j users can patch.
The current bug was either found or first exploited by Minecraft trolls, to bring down servers and clients via chat.
If you want to find issues in a code library, embed it somewhere in the hot code paths of a game or DRM system to maximize the number of eyeballs looking at every single instruction.
The problem is, there are a vanishingly small amount of engineers talented enough to find these kinds of things.
And if NSA wanted to hire a few hundred they’d have to go the defense contractor route which will inevitably lead to them getting 1 great engineer and 499 extremely mediocre ones.
I would look at things getting parsed and throw some fuzzers at it. Maybe data mining Github to use some real world strings for it. I think with that approach even my normal sized brain would find problems.
It is about the willingness to invest, not brainpower. If I was tasked to "improve security" at my current project, I could instantly tell you things that could be looked into, even though reasonably precautions are already taken and there are already processes around it in place. I bet it is the same for most programmers.
>I would look at things getting parsed and throw some fuzzers at it. Maybe data mining Github to use some real world strings for it. I think with that approach even my normal sized brain would find problems.
Given that you're mentioning fuzzers and a decent source of inputs you could use, I think you're either underestimating yourself or overestimating the actual "average" of software developers.
At one point, it seems that "everyone use this so it must be secure enough" replaced "we're a large company, did we spend enough time reviewing code of the open source stuff we use?".
It seems the Linus's quote "given enough eyeballs, all bugs are shallow", is not really true.
Imagine if a well funded agency like the NSA employed at least hundreds of full time developers whose job would be to sniff for those vulns. I'm pretty sure you could automate searching for those vulns, and that only the NSA has such tool.