Linux in the Enterprise: Security

Open-source software—panacea or peril?

Does the open nature of Open Source make it more vulnerable to attack? Or, does the ability to review code and submit bug fixes make Open Source superior to proprietary software? Felix Mohan presents the pros and cons

Borland positioned a backdoor in their database server ‘InterBase’ that allowed any local or remote user to take over the system as root. This backdoor stayed snugly in place for seven years and no one other than Borland was any wiser. Safe, or at least distanced from public scrutiny, Borland had no compelling incentive to remove the backdoor. Then, in July 2000, Borland released its source code to the public. Within six months the serious security flaw was discovered, and CERT published the vulnerability as an advisory in January 2001. This happened a few months after the uproar in April 2000 when it was exposed that the developers of the Microsoft’s FrontPage Web server had inserted a backdoor that lay concealed in the proprietary software for four years. The backdoor’s password was: “Netscape engineers are weenies!”—a barb that reflected the intense competition between Microsoft and Netscape at the time.

The Borland and Microsoft incidents may well encourage vehement testimony favouring open-source software since it is open for review by the public; but that should be no source for comfort in reality. Even some of the most widely reviewed pieces of open-source software have had significant flaws that managed to remain undetected for years, despite the innumerable eyeballs poring over them. For instance, some of the recently discovered buffer overflow flaws in Kerberos, an open source security protocol used for authentication, remained concealed, or at least unobserved, for over ten years! So, there is no guarantee that those scrutinising open-source code will find any flaws in the code, much less all of them.

Most people scrutinise open-source code to customise it to their unique needs, or they review code as part of a security audit. Others may do it to improve the code for altruistic purposes. Unfortunately, some scrutinise open-source code with the sole intent of lodging malicious code within it, or to uncover a flaw before anyone else does. Detractors of open- source software lambast the ease that is accorded to attackers in harming systems. They tend to propound the view that if code is distributed only as binaries, the bar will be raised high enough to deflect attackers away.

Shrouding closed-source software

But this argument does not hold water. While it is true that Trojan horses and other malicious code can be inserted into open-source code, that eventuality can occur just as well in proprietary code. A disgruntled or dishonest employee could do the deed and the likelihood of it being found out would be marginal.

Distribution of binaries too doesn’t provide much succour because any binary code that can run in a computer can be reverse-engineered, using decompilers or disassemblers, to re-create the source code for the product. An attacker can then scrutinise the reverse-engineered source code to detect and attack loopholes, much the same way as he would do to open-source code.

Keeping source code closed does not necessarily secure it. For proponents of closed-source software, a system cannot be truly secure when its source is open for all to read. For them, secrecy means security. However, in reality, many of the most secure systems available today are based on the open- source model. For instance, the US has recently adopted the Advanced Encryption Standard, a public algorithm, as its national standard, which will be used to protect the most sensitive traffic.

The shroud of secrecy over proprietary software leads not to true security but a false head-in-the-sand sense of security. One does not know what is in there, and one cannot verify it. And, one cannot check the integrity or motivation of the people who wrote it. Simply put, one has to blindly accept the assurance on security, which the proprietary software vendor hands out. This, very clearly, isn’t enough, considering the fact that their assurances have built-in disclaimers absolving them of legal penalties in case the software is flawed.

Eyeballing open-source software

If closed is taboo, is open the answer? While openness is essential for trust, the moot point is whether or not open-source software provides that trust. The basic open-source philosophy can be summed up as security through eyeballs. With thousands of people scrutinising the open-source code, bugs and security flaws are more likely to be found and reported—which may not happen in the case of a closed application audited by paid employees working behind closed doors, fired by varying degrees of commitment.

Then again, simply because open-source code is viewed by ‘lots of eyeballs’ does not mean that it is reviewed for security. If the code is complex or follows an uncommon design methodology, people are likely to be discouraged from reviewing the code. This situation may be worsened by the lack of documentation. Anything that makes it harder for the average user means fewer eyeballs. Most people only look at parts of the code they want to modify, which may only be a small section of the code; and they may not do so with security in mind. Many eyeballs are amateurs with only a rudimentary knowledge of security. Considering that many security problems are very subtle and may span large parts of the source code tree, an eyeball may miss the flaw.

Therefore, even if open- source code receives many eyeballs, it may not be more secure. And on the ground, there may not be the high quality auditing that people believe happens. Everyone presumes that someone else has done the proper security audit while in fact no one may have. This can lull people into a false sense of security. It is for this reason that security flaws in open-source software may remain undetected for many years.

Linux—the open source magic potion

In the case of the prime open-source software—Linux—the kernel may be more secure because it is under tighter control and receives expert code review by a core group led by Linus Torvalds himself. However, the many ‘applications’ that run on Linux do not get the kind of attention people normally expect. The Linux kernel 2.5.37 has 5.1 million source lines of code, whereas the Linux ‘distributions’ are much larger. For instance, the Red Hat distribution has 30 million lines and Debian has a whopping 55 million lines of source code, the sizes differing because of the kind of applications the vendor bundles into the distribution. Linux does not inherently provide the ease of management that systems such as Windows provide, which people have become used to. Therefore, vendors bundle their own management software with their distributions. Such software may receive a very small number of eyeballs for code review and therefore, may not be secure. It is, therefore, common to find vendors of Linux distributions regularly issuing security patches for flaws that affect their distributions. Thus, while Linux per se may be more secure, Linux distributions may vary in their security levels.

A matter of trust

Finally, the trust that one can repose in software, whether it is open or closed, is directly proportionate to the robustness of its security. Trust comes from perceived security; and Microsoft’s initiatives such as Palladium and Trustworthy Computing enable trust through enhanced security. Trust also comes from openness; therefore, the Microsoft source code is now available to governments for scrutiny if they so desire. In future, trust will come from legally binding assurances. According to Gartner, by 2008, the standard liability disclaimers in software licensing agreements will no longer protect software vendors against lawsuits stemming from breaches of fundamentally insecure software. In that legal environment, the open- source model will reign.

Felix Mohan is the CEO of SecureSynergy. He can be reached at felixmohan@ securesynergy.com