Slashdot Mirror
2014: The Year We Learned How Vulnerable Third-Party Code Libraries Are
jfruh writes Heartbleed, Shellshock, Poodle — all high-profile vulnerabilities in widely used libraries that rocked the software industry in 2014. Sadly, experts are now beginning to believe that these aren't the only bugs lurking out there in widely used open source code, just the ones that grabbed the most attention. It's beginning to look like one of the foundation concepts of open source — that with enough eyes, all bugs are shallow — is a myth. Of course, probably no one believes that all bugs are instantly shallow, no matter how open is the source, or that open source software is immune from bugs -- particularly ESR, coiner of the phrase.
Shellshock did not affect a "library", but an executable.
You're pretty fairly assuming that closed source software is bug-ridden crap capable of gross economic damage. Like OpenSSL. Because open sores suffers from amateur hour and people harping on many eyes but never fucking looking at a line of code, so that must be the case for everything else, too.
Let me tell you about my zombie carpenter friend. You can't see him or measure his effect on the world, but he pretty much owns humanity. Trust me, I have a github account.
A long time ago, I saw Bertrand Meyer (the Eiffel guy) give a keynote at ICSE, where he pointed out that the "given enough eyeballs, all bugs are shallow" claim is unscientific, because it can't be falsified: if a bug is not found, people can always say that there were not enough eyeballs, so "Linus' Law" still holds.
The security of the open source model isn't really the problem or the answer here. The problem is homogeneity. A million different sites and applications rely on just a few libraries, so that when a bug hits one, it has massive impact on the entire internet.
We also know that the answer isn't in rolling your own security. Very few people or organizations are likely to be able to securely implement their own version of TLS. Even the best packages of today didn't start out perfect, they had to iterate through several flaws to get to where they are today.
So perhaps the better answer is in having more packages to choose from? Instead of picking just openssl by default, it would be better to have a broad array of choices. With a dozen packages on the market, that might mean 11 times out of 12 the bad guys wouldn't exploit our site. If the packages are interchangeable, we'd be better positioned to switch them quickly in case of emergency.
John
ESR's claim has nothing to do with the frequency or discovery of bugs. All he says is that given enough observers, bugs are quickly characterized. It is implied that any given bug has already been discovered. There is no benevolent cohort of experts continuously auditing code bases and his statement doesn't claim there is.
Lurking at the bottom of the gravity well, getting old
one of the issues is that there are indeed *more eyes* but they are incentivised to look for exploits and sell them to the bug-buyers rather than report or fix them. I did a hands up poll (buyer beware) at our local OWASP chapter and over half had sold a bug to such an organisation. pretty shocking.
certainly, one of the first moderately important bugs I found, I was daft and got in touch with the software vendor and then faced legal action from them which luckily they saw sense and dropped. So many people nowadays just can't be bothered with that problem and can make a fast and low risk buck by selling the 0-day.
So all we need are 11 more sets of programmers to program free version of SSL 2-12?
Yes, and demand for them. But the big problem you're correctly implying is there's no economic justification that will drive this behavior. Maybe it will take a dozen big companies and foundations to drive this. Imagine if IBM, Microsoft, Google, RedHat, Yahoo, HP, Dell, Apache, Wikimedia, Mozilla, FSF, Apple, Intel, AMD, nVidia, Bungiesoft, and others each contributed their own versions of openSSL; each written in their own choice of language, using their own code, and building their own implementations of everything from the crypto through the command line interpreter logic. My company may decide we do more business with Intel, so we choose theirs. Or your company may be more Apple focused, so you'd choose theirs. In every case, we'd all nervously watch each other looking for signs of intrusions, hoping we won't be the victims, but knowing that alternatives exist if we are.
While a 1/12th scale incident of Heartbleed is still a huge problem for a lot of companies, it's no longer the catastrophe-sized disaster that Heartbleed actually was.
John
3) Port to to multiple architectures (and OS's) to catch bugs not reported by the original build environment. This is one of the approaches OpenBSD uses to improve security and was quite common in the open source software world when ESR coined the phrase.
The OpenBSD team found one very long lasting (30+ years) bug in the legacy BSD code when the Sparc64 build barfed.
A Shadeless room is a brighter room.