Saturday, September 27, 2014

ShellShock: Another indictment against the "many eyes make all bugs shallow" mantra of Open Source

A few months ago, the Internet was hit by one of the largest security vulnerabilities in its history: a years old bug in the OpenSSL cryptography program called "Heartbleed". The bug allowed any attacker who had the time to attack a server running OpenSSL and retrieve sensitive information like usernames, passwords, and other private information. When discovered, the bug was quickly patched and excuses were made. This was not an indictment of the open source model, advocates argued, but the fact that OpenSSL was underfunded and understaffed.

Earlier this week, another bug called ShellShock surfaced which has the potential to be just as big and destructive as Heartbleed. The bug has to do with the way the popular UNIX/Linux shell called bash processes variables. It allows anyone who knows how to exploit the bug the ability to run arbitrary commands on any server that's vulnerable to the bug. Unfortunately, 'any server' could possibly mean nearly every UNIX/Linux server deployed in the last 20 years.

Read that carefully: the bug is 20+ years old. It came into being in Bash 1.1. And it allows attackers to take over a vulnerable system and do pretty much anything they want with it.

We in the open source world like to tout that our software is secure because the code is available and people can look at it to discover and fix bugs. Popular developer and open source advocate Eric Raymond once said "with many eyes, all bugs are shallow". But we now have two examples in two major and commonly used pieces of software that have somehow missed being found for YEARS and, in one case, nearly TWO DECADES.

While I'm not intimating that these flaws are deliberate, one has to wonder how large flaws in such critical systems could go completely unnoticed for such a long length of time. It smacks of sinister influence by some organization, developer incompetence, or it says that nobody is actually reviewing the code.  If any of those are true, then it means open source is absolutely no less vulnerable to critical holes than its proprietary cousins and that should concern us deeply.