For all of its benefits, open source, one of the mainstays of The New IP, and hot topic in discussions around network functions virtualization and software-defined networking, has come under yet greater scrutiny in the wake of an avalanche of serious open source security vulnerabilities in OpenSSL, TrueCrypt, Bash (a Unix shell), Debian, Firefox, and numerous others.
Open source, notoriously exemplified by Linus's Law, an adage quipped by software developer Eric S. Raymond: "Given enough eyeballs, all bugs are shallow," or "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone," is now facing questions as to whether or not it's a fit for the world of telecom.
In fact, at the Annual Advanced Cybersecurity Security Center Conference in November, Andy Ellis, chief security officer, Akamai Technologies, said, "The Florida Everglades happen to be shallow as well. It's still a swamp," when referring to open source and Linus's Law.
Not enough eyeballs
As it turns out, some open source projects do not have that many eyeballs reviewing them. Most projects are managed by very few people working for very little (if any) money. For example, OpenSSL -- a security tool that is extremely widely used -- has but an 11-member team behind it.
However, just because open source is possibly not better than proprietary code does not mean that it's worse. What's more, open source is not going away any time soon. Therefore, it bears discussion how major vulnerabilities can go undetected for so long in open source projects -- and how to try to prevent the problem in the future.
"The 'many eyes' theory … doesn't work because security code review is hard, mostly boring work," noted Roger A. Grimes in an InfoWorld column. "Those who do it well are probably being paid to do it for a living, and they don't have time to peruse every bit of open source code on the Internet."
It would thus behoove an organization that relies upon open source solutions to thoroughly audit these tools themselves -- or hire a third party to do so. Penetration testing and other security help may be available through the organization's cyber insurance carrier.
Of course, many have called for additional donations to be made to open source projects -- a worthy notion indeed but not a guarantee. Whether or not an enterprise chooses to contribute its fair share, it still must take solo responsibility for ensuring the security of the tools it uses.
Clues in the code
Because of open source's reputation for poor code quality and lack of helpful comments, the task of open source code review is not an easy one. Those who actively work to weaken open source security prey upon these factors. Plus, so many of the vulnerabilities are simple and look like mere typos so they are as easy to miss.
"The way most people try to [maliciously] slip in backdoors is with carefully hidden incorrect checks in places that allow privilege escalation," said technology blogger Stephen Gallagher in an interview with The New IP. "For example, a common trick is to hide it in a test for a command's arguments, or a function's parameters, for certain invalid options."
Perfect code review alone may not protect against malware malefactors, either. Gallagher pointed out another inherent security issue with open source: the presumption that "the sources given out match the sources actually used to build the final products."
"It's very difficult to prove this," says Gallagher, "but at least by giving out the pristine sources, all consumers of open source technologies can at worst rebuild it themselves and be certain." However, "This comes at the potential cost of voiding their support contract if they get caught," he added.
To help with this, Red Hat offers reproducible builds of Fedora to its users. Still, as the company itself notes, even this caution presumes that the toolchain used to rebuild the software is safe and trustworthy.
As the open source trust and security issues pile up, all the community can do, then, is be vigilant.
— Joe Stanganelli, Freelance Contributor, special to The New IP