OpenSSL: the New Face of Technology Monoculture 113
chicksdaddy writes: "In a now-famous 2003 essay, 'Cyberinsecurity: The Cost of Monopoly,' Dr. Dan Geer argued, persuasively, that Microsoft's operating system monopoly constituted a grave risk to the security of the United States and international security, as well. It was in the interest of the U.S. government and others to break Redmond's monopoly, or at least to lessen Microsoft's ability to 'lock in' customers and limit choice. The essay cost Geer his job at the security consulting firm AtStake, which then counted Microsoft as a major customer. These days Geer is the Chief Security Officer at In-Q-Tel, the CIA's venture capital arm. But he's no less vigilant of the dangers of software monocultures. In a post at the Lawfare blog, Geer is again warning about the dangers that come from an over-reliance on common platforms and code. His concern this time isn't proprietary software managed by Redmond, however, it's common, oft-reused hardware and software packages like the OpenSSL software at the heart (pun intended) of Heartbleed. 'The critical infrastructure's monoculture question was once centered on Microsoft Windows,' he writes. 'No more. The critical infrastructure's monoculture problem, and hence its exposure to common mode risk, is now small devices and the chips which run them.'"
OSS vs Reality (Score:5, Insightful)
In theory (the way OSS evangelists tell you) as a software package gets more popular, it gets reviewed by more and more people of greater and greater competency. The number of people using OSS packages has exploded in the past 10 years, but the number of people writing and reviewing the code involved doesn't seem to have changed much.
Apples and oranges (Score:5, Insightful)
With open-source software, a monoculture isn't that bad a thing, as the Heartbleed exploit has shown. When something bad is discovered, people jump on it immediately and come up with a fix, which is deployed very very quickly (and free of charge, I might add). How fast was a fix available for Heartbleed? Further, people will go to greater lengths to make sure it doesn't happen again. Look at the recent efforts to rewrite OpenSSL, and the fork that was created from it.
None of this happens with proprietary software. First off, the vendor always tries to deny the problem or cover it up. If and when they do fix it, it may or may not be really fixed. You don't know, because it's all closed-source. It might be a half-ass fix, or it might have a different backdoor inserted, as was recently revealed with Netgear. What if you think the fix is poor? Can you fork it and make your own that's better? No, because you can't fork closed-source software (and certainly not selected libraries inside a larger closed-source software package; they're monolithic). But the LibreSSL guys did just that in the Heartbleed case.
Finally, monocultures aren't all that common in open-source software anyway; they only happen when everyone generally agrees on something and/or likes something well enough to not bother with forks or alternatives. Even the vaunted Linux kernel isn't a monoculture, as there's still lots of people using the *BSD kernels/OSes (though granted, there's far more installations of the Linux kernel than the *BSDs).
Companies using OpenSSL should help out (Score:3, Insightful)
I have been a bit surprised that all these companies using OpenSSL (Google, Yahoo, Facebook, etc) haven't ensured that this critical piece of technology is getting the support it needs to be done correctly.
What other technology that is critical are these same/dependent companies overlooking in their investment of dollars in Open Source software??
Will be interesting to see what happens going forward.
The bad guys don't have time to master second tier (Score:2, Insightful)
But the rest of us do!
It's a silly argument. Put your eggs in one basket... then guard the basket. 2-3 FT developers doesn't cut it when there are so many attackers and the motivation is much greater than bragging rights at def con.
Recognize limitations of volunteer efforts (Score:5, Insightful)
I am not anti-volunteer; I spend a lot of my time volunteering.
But you need strong leadership.
Otherwise, everyone does what they want to, which leaves huge holes in the project.
Whether a piece of code is open source or closed source doesn't matter. The quality of the leadership of the team that produces it is vital in both cases.
Re:OSS vs Reality (Score:2, Insightful)
We're reactive, not proactive - why look for problems if the software is already working?
This is why we missed Heartbleed, because there's no compelling reason to keep working once the product gets a green light. There never will be a compelling reason. The problem has no solution that doesn't involve throwing money at something that will never have a payoff...so we won't ever do it. People don't do things unless there's an observable negative to *not* doing them.
Specious Argument (Score:4, Insightful)
I'm not sure it's a valid argument. The probability of errors that may be found in a given system is proportional to the complexity of that system. Likewise the cost to maintain and evolve a system is proportionally tied to its complexity. It is therefore a worthy to goal to reduce system complexity whenever possible. If network communication infrastructure is taken to be the system, then it naturally follows that the fewer implementations that exist for performing SSL/TLS communication the less likely there will exist security vulnerabilities. Relatedly the cost to identify and correct vulnerabilities will be proportionally smaller. Said simply, it's much easier to guard one door than it is to guard many.
Suggesting that a "monoculture" is bad relies upon the same faulty premises of "security through obscurity." The failure with respect to OpenSSL and Heartbleed wasn't the monoculture. It was the lack of altruistic eyes scrutinizing it. More implementations would have only required more eyes.
Re:OSS vs Reality (Score:5, Insightful)
That is the reality of the situation. In the fantasy land of OSS evangelists, thousands of highly skilled coders are constantly auditing big OSS projects.
Re:Is anyone surprised? (Score:5, Insightful)
Re:Is anyone surprised? (Score:5, Insightful)
OpenSSL is one great example for what I dubbed "Monkey Island Cannibal security" in my talks (yes, believe it or not, you can actually entertain and inform managers that way, you'd be surprised how many played MI, and even if not that's at least something they can understand). But that whole Monkey Island spiel works as a perfect example for security blunders where one point gets improved over and over because everyone thinks that's the only point it could fail while the rest of the security system gets neglected even though the security problem is obviously there.
For those who don't know MI (or who forgot), there is a moment in Monkey Island where the cannibals catch your figure and lock him up in a hut. You can escape that hut via a loose panel in the wall. Now, every time the cannibals catch you again, the door of the hut gets more and more elaborate and secure, to the point where that bamboo hut has a code lock reinforced steel door befitting a high security vault in the end. Which of course has no effect on your chances to escape since you never pass that door (at least on your way out).
The point is that the cannibals, much like a lot of security managers, only look at a single point in their security system and immediately assume that, since this is their way of entering the hut, it must also be the point where you escape. Likewise, the focus on auditing OpenSSL lies always on the crypto routine, and you may assume with good reason that this is one of the most audited pieces of code in existence.
Sadly, the "hut" around it is less well audited and tested. And that's where the problems reside.