Open Source Software: Secure Except When It Isn't

Linux and open source used to be 99% secure -- or so we thought. We laughed at the poor, hapless users of Windows, an OS that seemed to suffer a new exploit hourly. We were smug and thought ourselves protected by Linux's superior design, with security built-in and not added as an afterthought. Most of all, we thought ourselves protected by the thousand upon thousands of eyes that were pouring over the code and making sure that any vulnerabilities that snuck through were caught by the white hats long before the black hats had a clue.

That was then; this is now. We open source proponents are no longer so cocksure when evaluating the security of the software we use, and we definitely don't laugh so loud at Windows users as we once did, at least about security issues. The reason for the latter is that Microsoft has done an admirable job of upping its game on the security front. As for the former, we've seen proof from exploited-in-the-wild vulnerabilities like Heartbleed that major security holes can find their way into our code and remain undiscovered for more than long enough to become exploited by the bad guys.

Along the way we've discovered a major fallacy in our assumptions on the ways and means of open source security. All eyes aren't watching all of the code.

Heartbleed, I'm sure you'll remember, was a nasty little vulnerability discovered in 2014 in the OpenSSL cryptography library. Among other things, it compromised keys used to encrypt network traffic and allowed hackers to steal X.509 certificate keys, user names, passwords, instant messages, emails, documents and more without leaving a trace of an intrusion. Like most security vulnerabilities, the hole was the result of a relatively easy to see coding blunder, but it was in the code for two years before it was discovered.

What went wrong?

It turned out that OpenSSL, although widely used, was underfunded, receiving only about $2,000 per year in donations. The project was basically being maintained by two developers who more than had their hands full and who might have been in a bit over their heads on security issues. This was a wake-up call for the open source community, which prompted the Linux Foundation to quickly react and create the Core Infrastructure Initiative to adequately fund critical projects so they could get up to speed on security and other issues.

The problem was solved. Linux users could go to sleep at night knowing that if their system were to be hacked, it most likely wouldn't be from a vulnerability built into the code. Linux was 99% safe again.

Close, but no cigar. Or, as Maxwell Smart used to say, "Missed it by that much."

There is still a flaw in the open source security model which the Core Infrastructure Initiative only partly addressed. Remember the thousands and thousands of eyes looking for vulnerabilities in the code? While that may be true in a generalized sense, there are some small but important projects that are flying under the radar and don't seem to be getting the necessary attention.

Take the recently discovered vulnerability in LUKS, the Linux Unified Key Setup used in disk encryption. This is another nasty little bug, and it's evidently been in most distributions since Linux 2.6, which has been around since 2003. As Steven J. Vaughan-Nichols pointed out in a ZDNet article, this isn't an obscure coding error that would take a rocket scientist to figure out: "Just like the OpenSSL Heartbleed security hole, once you look at the code, the problem leaps out at you. But, if you don't look, it just hides there in plain sight. Open-source security only works if you actually read the code."

I'm sure there are thousands of eyes looking at the vast majority of code in Linux and open source, just as I'm sure that the open source software model produces code that tends to be more secure than that produced by closed source developers. However, I also respect the old adage that a chain is only as strong as its weakest link. We need to spend more effort finding the weaker links and strive for that 99% goal.