OSS Security

[May 30, 2002] BW Open Source Software May Offer Target for Terrorists, According to Study by Alexis de Tocqueville Institution's Committee for the Common Defense

WASHINGTON--(BUSINESS WIRE)--May 30, 2002--Terrorists trying to hack or disrupt U.S. computer networks might find it easier if the federal government attempts to switch to "open source" as some groups propose.

"Opening the Open Source Debate", a soon to be released white paper by Alexis de Tocqueville Institution details the complex issues surrounding open source, particularly if federal agencies such as the Department of Defense or the Federal Aviation Administration use software that inherently requires that its blueprints, source code and architecture is made widely available to any person interested - without discretion.

In a paper to be released next week, the Alexis de Tocqueville Institution outlines how open source might facilitate efforts to disrupt or sabotage electronic commerce, air traffic control or even sensitive surveillance systems.

Unlike proprietary software, open source software does not make the underlying code of a software confidential.

"Computer systems are the backbone to U.S. national security", says Fossedal, chairman of the Alexis de Tocqueville Institution and its Committee for the Common Defense, which will release the study. "Before the Pentagon and other federal agencies make uninformed decision to alter the very foundation of computer security, they should study the potential consequences carefully."

ZDNet Tech Update

March 20, 2002 Flaws turn security spotlight on open source software
With security flaws in widely used open-source applications coming to light, even open source insiders are beginning to question the community's ability to cope. "I see a lot of bad software being done," says Theo de Raadt, founder of the OpenBSD open-source effort.

Wide Open News -- Security Through Obscurity

... Associates. The theory of open source security is simple, and it is endemic throughout the entire open source community. The theory ...

News: Too much trust in open source?

... theory Open-source software's main claim to security is that because anyone can
view the source code, developers can constantly look for bugs and fix them. ...
zdnet.com.com/2100-1104-864256.html - 59k - Cached - Similar pages

[Mar 10, 2001] Information Security MagazineBY PETE LOSHIN OPEN-SOURCE SECURITYMarch 2001OPEN SOURCE UNDER THE HOOD. Columnist PETE LOSHIN (pete@loshin.com) is a senior editor-at-large for Information Security. He produces the Internet-Standard.com Web site and has authored more than 20 books on Internet protocols and security.

Vendors are increasingly including open-source components in their commercial products. What impact does this trend have on product security?

The days are long gone when all you needed to start your own software company were a compiler and a computer. Creating commercial off-the-shelf (COTS) products from scratch in today's market is a daunting task for any but the biggest software companies. Smaller vendors have to compete with the likes of Microsoft, Sun and Cisco, with only a fraction of the resources.

Almost no one can afford to build their own new products from scratch anymore, and the problem is magnified for vendors of network appliances: They've got to deliver a functional, competitively priced server, including software and hardware, while still turning a profit. Vendors of other products, from operating systems to software suites to end-user workstations, are feeling the pinch as well.

Considering this environment, it's not surprising to find vendors increasingly turning to open-source code when creating new products. Yet buyers may not always be aware that inside their shiny new firewall lurks an open-source OS, such as Linux or FreeBSD. Network security appliances designed to do firewalling, intrusion detection and other security functions often rely extensively on open-source OSes and utilities. But many other products include open-source components as well. Apple's new Macintosh OS X, for instance, is based on Free BSD 3.2 and the Mach 3.0 project from Carnegie Mellon University. Apache, BIND, Sendmail and Perl are all widely used in both commercial and non-commercial products.

Among the obvious reasons developers turn to open source are cost and security. Clearly, vendors can keep their costs down when they don't have to build their own components or buy licenses for commercial components. Why build a Web server when you can use the best one around-Apache-for nothing? Why build your own OS when you can use FreeBSD? Why not include open-source security utilities with a commercial security product?

While some people automatically assume that open-source OSes are more secure than proprietary OSes, it entirely depends on how the code is used and supported. When done right, open-source components add real value to commercial products-and are likely to be at least as secure as closed-source components.

So what exactly is open-source code, and what impact does it have on product security? How can it affect your systems and networks? How can you tell if the product you're using incorporates open source? And how can you become an intelligent consumer of products that use open source?

... ... ...

Risks and Rewards of Open Source in COTS Products
The common assumption among developers and engineers is that the "many eyes" approach to open-source code projects makes it inherently more reliable, robust and secure than closed-source code. However, recent revelations of glaring holes and vulnerabilities in sometimes quite old and widely used open-source code have led some to question the validity of this assumption. Steve Lipner, manager of the Microsoft Security Response Center, points to the recent discovery of vulnerabilities in MIT's Kerberos network authentication software, "where buffer overruns went undiscovered for nearly a decade" in the widely distributed and implemented open-source code. (Microsoft released a closed-source-and slightly non-standard, and thus non-interoperable-version of Kerberos with its Windows 2000 suite.)

While few open-source advocates still claim absolute security superiority over closed source, most experts seem to agree that open source has the potential to be at least as secure, if not more secure, than closed source. For one thing, open-source code by itself should have no real adverse effect on system security. "The negative ramification that people cite is that - anyone can look at the code to find holes,'" says Bastille's Jon Lasser. But that works both ways, since open-source vulnerabilities are (in theory anyway) vetted by a much larger community of developers and engineers.

"I'm not convinced that there are any significant real advantages to going with closed source unless there is something about the security mechanism itself that intrinsically can't stand up to examination" says Paul Robichaux, a senior solutions architect for EntireNet and author of several books on Microsoft products.

Robichaux stops short of unqualified endorsement of the open-source security model, cautioning that having "more eyeballs looking at [open-source code] is no guarantee of quality." Moreover, for some systems, such as national security programs, close public scrutiny is unwarranted. "If you look at the authentication system…the [U.S.] National Command Authority uses when they want to tell somebody to launch a nuclear missile, you probably would not gain any security from having many more eyeballs looking at that."

Microsoft's Lipner acknowledges that "no software is free from flaw," while suggesting that "the difference between products lies in how actively vendors seek out the flaws and then fix them." According to Lipner, Microsoft "pays top dollar to ensure that its software is scrutinized by the best minds in the industry rather than taking the open-source approach of relying on hobbyists and--someone else' to scan code in their spare time."

Microsoft's official position on the relative security of closed- and open-source software, according to Lipner, is that "the difference lies in how we-do' security. The most fundamental question to ask when examining the security of any software is whether or not the design and development process results in a sound and secure design and a solid implementation." Microsoft isn't opposed to open reviews of cryptographic protocols and algorithms; Lipner says that they "can definitely improve security. These are generally simple enough that academic or external review can find issues and add value."

However, Lipner points out that securing large software systems calls for "a substantial and often costly level of resources applied by a full-time team"--which, he says, will only work if the costs can eventually be recovered by product revenue.

According to Bastille's Lasser, "Anyone using open source can fix the code, or pay someone else to fix it. And anyone can examine it." One result of this all-hands-on-deck model is the potential for discovering backdoors. For instance, Lasser points to the Borland InterBase, initially a proprietary product that, after seven years, was released as open-source code. The proprietary version contained a backdoor that wasn't discovered until six months after the code was opened.

Kurt Seifried, senior analyst for SecurityPortal.com and project head for the Linux Security Knowledge Base, explains that attackers don't need access to the source code to find and exploit problems. For instance, Microsoft issued more than 100 security advisories in 2000, and new bugs related to IIS or IE are publicized on Bugtraq and NTBugtraq all the time.

That's not to say that open-source code has no downside, particularly when implemented in commercial products. It all depends on who is doing the implementation and how support is being provided. Lasser suggests that in order to keep customers' code current, vendors should offer opt-in e-mail lists for up-to-date news about the product, be up-front about any security problems and provide patches online that have been cryptographically signed. While vendors such as Red Hat, SuSE and Mandrake offer these services, "few vendors do all of this," he says.

Seifried, singling out OpenBSD, says some open-source projects are particularly well suited to secure deployment in commercial products. "They sat down and spent a large number of man-years auditing it heavily and now have a pretty solid and secure codebase to work from." Many commercial vendors use OpenBSD--as well as FreeBSD and NetBSD--for firewalls.

However, inappropriately using a secure and open program is dangerous. "It's almost always a question of how the products are used, rather than what they are," Lasser notes. "One of the defining characteristics of the security problem is that these evaluations are fluid, depending largely on new exploits and classes of exploits that are discovered." Just because OpenBSD is noteably secure doesn't mean it's not still vulnerable to common exploits of programs like FTP, DHCP and Send-mail. If someone used OpenBSD as part of a "secure FTP solution," but used an insecure FTP implementation, "they're toast," says Lasser.

Buying Open Source Under the Covers, Intelligently
Vendors incorporate open-source code in their products differently, so simply scrutinizing brochures or Web sites isn't enough. Some vendors make open source an important part of their marketing strategy, pointing to it as a source of strength. Examples include C2Net and Linux-based firewall vendor Cybernet Systems Corp. (www.cybernet.com).

Network security appliance vendors sometimes include lists of software installed on their hardware. Read the fine print in datasheets for Sun's Cobalt RaQ, Qube and other network appliances (www.sun.com), and you'll see that those products use the Linux 2.2 kernel. Axent's (now Symantec's) Raptor firewall appliance (www.symantec.com) is also based on the Cobalt RaQ. Other vendors are less forthcoming, releasing appliances based on "proprietary" OSes that are, in fact, open-source based. For example, the FireBox network appliance from NetWolves (www.netwolves.com) is based on FreeBSD-but the company's Web site refers to it as a "Unix-based FoxOS" operating system.

The greatest benefit of buying products that incorporate open source can also be part of the greatest drawback--that is, the fact that vulnerabilities and exploits for leading open-source products are widely published. This means fixes are usually made available quickly, but it also means that if you take too long to update your systems, they will be vulnerable to script-kiddiez and other attackers.

Bastille's Lasser suggests that vendors should provide proactive support, notifying customers of vulnerabilities and fixes. However, in his opinion, knowing where a particular piece of a system originated, whether open source or not, is not always very useful. "Sure, you could ask whose TCP/IP stack they used, but you won't know which version, and the optimal solution varies by week, application and phase of the moon," Lasser opines. But he also acknowledges that "there's nothing especially specific to open source about any of this."

In the final analysis, it's up to consumers to keep track of what open-source code is running on their systems--if only to keep them up to date. SecurityPortal's Seifried suggests asking vendors for a list of their product's security patches. "If they don't have any patches, I wouldn't buy it. Nothing is perfect.

"Open source is like any technology," he adds. "The implementation can be good or bad. Vendors that use open source and issue timely updates, proactively audit code and so on are good; vendors that don't should be avoided if possible."

Could You Do It Yourself?
Vendors use open-source code to build their products, so why can't anyone else? Well, nothing's stopping them, but the question is whether they can afford to (see box, below). A vendor can afford to put significant resources into putting together a package from open sources as long as they anticipate revenues. Seifried says it's a matter of convenience. "I can easily download the Linux kernel source and all the source code for software I need. Turning that into a working e-mail server, on the other hand, is a completely different matter."

According to Lasser, there are three other good reasons not to "roll your own." First, commercial versions of open-source programs usually incorporate proprietary extensions that add significant value. For example, C2Net's Stronghold Web server adds strong encryption and other features to Apache. Also, with proprietary products you get the benefit of quality assurance. And finally, you get support. "You're not paying for the software so much as you are to have someone to complain to when things break," Lasser says.

Buying commercial products based on open-source components may give users the best of both worlds. Microsoft's Lipner suggests that "proprietary systems are better reviewed, better tested and have a more robust process for dealing with security vulnerabilities when they are found"-though he was thinking more of entirely proprietary systems like those available from Microsoft. Everyone seems to agree that a proprietary product provides greater ease of use, better support, more convenience and more features, whether or not the proprietary product incorporates open-source code.

OPEN SOURCE INSIDE

Download pdf

BACKDOORS: OPEN OR CLOSED?

Backdoors are the security manager's nightmare. About the worst thing that could happen from a security standpoint would be the deployment of a system that includes an unknown backdoor.

The fear of backdoors "has probably been the biggest drag on the adoption of open source in the commercial world," says security expert and author Paul Robichaux. He recommends taking great care in reviewing any code brought in-house. "If you're using open-source code and you're not already reviewing it very carefully, you're being stupid and you deserve what you get," he says.

In the open-source world, it's likely that any externally injected malware (such as a Trojan) will be caught before it can be incorporated into production systems. But Robichaux warns that when you are buying compiled products (such as security appliances)--whether open source or not--"you never know what's going to be in those."

Rumors of backdoors inserted into commercial products have persisted for years. According to Robichaux, it's plausible (though never confirmed) that government agencies such as the National Security Agency (NSA) could "go to Microsoft or Sun or Oracle or whoever and wave their magic national security wand." As a result, "The product you're using will have a hole in it, but you won't necessarily find out."

Those using open-source code-whether it's the native code itself or a COTS product based on it-face a Catch-22 when it comes to backdoors. On the one hand, attackers are more likely to try to insert a backdoor into open-source code because, unlike closed source, it's out in the public domain for everyone to play with. On the other hand, they will be less likely to succeed because there are so many other people, with different goals, looking at the same code, which increases the possibility that it will be noticed.

BUILDING YOUR OWN FIREWALL

Time is money, and it's well worth spending a few thousand dollars to save a few weeks of a security manager's time.

When the Internet was still a research network, it was built on BSD/Unix systems. BSD derivatives, like all Unix flavors, are designed from the ground up to run on networked devices. So it shouldn't surprise anyone that so many firewalls and Internet servers are based on BSD-related distributions. Linux, with its relatively easy-to-use firewalling and Network Address Translation (NAT) functions, is also a popular platform for security applications.

If you have Linux, BSD or Unix expertise--or at least plenty of time--BSD- and Linux-based firewalls can be cheap and effective security solutions. But doing it yourself can be an invitation to disaster unless you're sure you've done everything right.

Once you decide to build your own firewall, you must install the operating system as securely as possible, and then create firewall rules to keep out all unauthorized traffic. That means building security policies first--a prerequisite for any firewall.

First, you must choose the most appropriate OS. Some prefer Linux for ease of use and widespread support; others find one of the BSD flavors (OpenBSD, NetBSD, FreeBSD, etc.) stronger (though perhaps less user friendly). If you choose Linux, you now have the option of using the 2.2 kernel, which provides firewall support with packet filtering by the ipchains program; or the 2.4 kernel, which uses the iptables program to create stateful inspection firewalls.

The next step is to get a trustworthy distribution: that means downloading from a trusted Web site or buying it on CD-ROM-and checking the distribution's digital signature. You'll want to review the source code before compiling it, and you should compile the kernel with only the drivers that are absolutely necessary.

Once installed, you'll need to turn off all extraneous services and harden the operating system in other ways (see Resources). You can do it by hand, or use a Linux-hardener (for example, the Bastille hardening scripts). Then, you've got to develop your firewall rules: what kind of packets should be filtered-both inbound and outbound-what applications are permitted, and so on.

Building and configuring the box, of course, is only the first step. Once the firewall is in operation, you must constantly monitor logs for suspicious activities, watch out for security alerts and install security patches as soon as they are available.

Some of these tasks (setting firewall rules and staying on top of security alerts, for example) are necessary with any firewall. But if you roll your own, you don't have the option of outsourcing any of them to a commercial firewall vendor.

RESOURCES

Download pdf

Recommended Links

---

In case of broken links please try to use Google search. If you find the page please notify us about new location

T.REX Open Source Firewall

Old_opensource_whitepaper Ken Brown Paper

• IS OPEN SOURCE INSECURE - Roaring Penguin Software -- some interesting consideration, despite the religious zeal of the author.
• OPENING THE OPEN SOURCE DEBATE - Roaring Penguin Software -- updates
• White Paper Attacks GPL
• Anti-open source ‘whitepaper’ devastated | The Register -- this is a Register, yellow paper, you know ;-)
• Wired News- Did MS Pay for Open-Source Scare
• Wired News Report Flays Open-Source Licenses But despite its hasty un-publication, the full report -- called "Opening the Open Source Debate," by Kenneth Brown of the Alexis de Tocqueville Institution -- still made it onto Slashdot on Monday, where its low opinion of open source was roundly criticized.
• Cyber Security Think Tank Blasts Security Of Open-Source Software Tech Daily
• LWN Response to Mr. Brown's critique of Open Source Software.
• LWN Letters to the editor
• NewsForge Anti-Open Source lobbyists need love, too  This is Roblimo, so it's a light reading. I like his stance about "WordPerfect, a fine proprietary program written by freedom-loving Canadians". Whas not  not the original WordPerfect produced by mormons ?  

  But we were talking about software. Or were we talking about Thomas Edison and Nicola Tesla? I mentioned an impromptu lunchtime conversation with AdTI president Ken Brown. That's where he told the old story about how Thomas Edison, in an attempt to market his DC power generating systems over Tesla's technologically superior AC systems in the 1890s and the first years of the 20th Century, sponsored demonstrations of animals -- even an elephant -- being electrocuted with AC, and invented the electric chair -- powered by AC -- to prove how dangerous AC was, presumably so that utility companies would choose Edison's DC. Brown used this story as an example of Edison's brilliance and business acumen. He talked of Edison in glowing terms as the "winner" of the AC/DC battle with Tesla -- and of how Edison and his backers later "bought out" Tesla and his backers' AC patents and business and used them to dominate the electric power marketplace. The only problem is, Edison and his backers did not buy out the Tesla camp. Tesla's primary financier, George Westinghouse, bought Tesla out -- in a deal that was not considered fair to Tesla by most observers, but still left Tesla well-off by the standards of the time -- and went on to build a huge company that made AC motors and generating plants. Those pesky facts! Well, they're not important, are they? Imagination and marketing prowess and competitive ability, those are what make America great! Guys like Tesla, mere engineers and scientists, are tools. They're the kind of people who believe in all that GPL gobbledegook, you know. They talk about "the common good" and other such twaddle, not about profits. I felt like an imbecile, sitting there in my casual clothes with my thoughts about software users and their needs, at a table with Ken Brown and two of his AdTI compatriots, all dressed in well-tailored dark suits, talking about the dangers of those pesky users not being willing to keep making software titans richer and richer, forever and ever, and about how that GPL nonsense must be stopped or no one will ever make any money writing software ever again, and even other Open Source licenses are dubious. I mean, you let just anyone look at your source code, and the next thing you know terrorists will know all your secrets and hack into all your computers and make your air traffic control system stop working so all the airliners run into each other, right? Or something. I was almost scared, after that dose of propaganda, to go home and sit down in front of my computer full of Linux and other Open Source programs. I was relieved when no terrorist hand leapt from the screen and grabbed me by the throat. Even now, a week later, I worry that terrorists may have infested Bluefish, the GPL-licensed program I am using to write this article. Are my words being twisted even as I type them? Wouldn't I be better off using something safer and more American (Bluefish is developed by a team of programmers all over the world) like ... MS Word? Or at least WordPerfect, a fine proprietary program written by freedom-loving Canadians

BW Online December 11, 2001 Is Open-Source Security Software Safe See also discussion SecurityFocus HOME News Is Open-Source Security Software Safe

Will the average bank care if the hacking underground can examine the basic source code of the security software protecting its networks? That's what information-security company Guardent is about to find out.

On Dec. 11, the Waltham (Mass.)-based company rolled out a hardware security appliance that relies solely on open-source programs to protect customers. Guardent will use these appliances, priced at $1,500 a pop, to monitor and guard corporate networks. That's a fraction of the cost of most integrated security appliances.

One small step for Guardent, one giant leap for open-source security. Corporations are loath to take a chance on a piece of security software they don't completely trust. But Guardent doesn't seem to be worried. Open-source proponents have long argued that their software is more secure due the exposure of the raw code to thousands of eyeballs, and the ability of anyone using the software to incorporate code changes to quickly patch vulnerabilities. What's more, Guardent will emphasize top-quality service first, good software second. "The thing that has the value is the service, rather than the software itself," says Guardent co-founder Daniel R. McCall.
 

Musings on open source security models -

Common sense would seem to indicate open source software is insecure because, for many, secure means hidden, secret. Recent discussions on several security-related mailing lists have revolved around keeping the names of servers secret, as if hiding information makes networks secure.

Others see open source as the means to secure operating systems. Some of the more secure systems available are based on the open source model. Many don't trust closed proprietary systems that can't be examined and verified for secure coding. To them, it's a myth that such systems are somehow inherently insecure, even though this belief is widely held.

In cryptography circles, they have a saying: The security of an algorithm should not depend on its secrecy. Now, this maxim is equally applicable to security software in general. Algorithms can be reverse-engineered. Protocols can be cracked through analysis. That which is hidden and secret will eventually be revealed. A secret, once lost, is gone forever and cannot be regained. Security through secrecy is largely a myth.

The argument then goes on, from the closed source camp, that secrecy or obscurity, when applied to an otherwise secure system, improves the security. It slows up intruders and, even when the secrecy is broken, the security remains as it would have been with open source.

So, all other things being equal, a secure system that isn't open source should be more secure than a secure system that is open source. Sounds reasonable.

Is it reasonable, though? Can all other things be equal? Are there ways in which secrecy and closed source code can actually compromise security?

The nature of common sense
There are many opinions and definitions as to what comprises "common sense." By one definition, common sense is the "future application of past experience." This definition allows for the possibility that what some refer to as common sense may, in fact, be wrong.

People unfamiliar with the open source model are accustomed to keeping their source secret. When their source does becomes public, it's almost always related to a security breach or the threat of a security breach.

Revelation of code developed and maintained in secret also often results in the discovery of previously undetected flaws and security holes. It's no wonder, therefore, that those accustomed to the closed source model of development view open source as insecure. Their past experience with security breaches colors their conviction that security goes down the tubes when source code becomes public.

It's in their "future application" of that "past experience" that common sense fails. Their past experience really no longer applies, since the conditions have changed.

The nature of secure software
Secure systems shouldn't depend on the secrecy of the source. What is it, then, that makes a system secure?

I offer this as a guideline to security:Secure systems require quality software utilizing secure coding techniques implemented and installed in a manner consistent with security guidelines and policy.

Myths regarding security and open source software
The following are some of the myths that contribute to the belief that open source is insecure:

Myth 1. There is no source control in open source software.

Those of us who develop open source software tend to howl with laughter over this one, but it's a criticism I hear quite a lot. Some folks actually believe open source software is developed with total disregard for tracking, accountability, or control. Nothing could be farther from the truth. With large and diverse development teams being the norm in the open source world, source control is a necessity, not an option.

Recently, a researcher at a national laboratory made such a remark to me. My reaction was to wait until I saw him again, weeks later, then innocently regale him with a number of stories and incidents arising out of "source control incidents" in open source. Many of these were taken from CVS (Concurrent Versions Systems) log announcements. He was utterly amazed at the level of source control in use and hasn't remarked on the lack of source control since.

Myth 2. No one really looks at the source.

The open source camp proclaims the source is available for anyone to examine. The closed source camp counters that people either don't have the time or the skill or won't invest the effort to examine it. Since the source isn't examined by everyone or examined by them personally, the argument goes, it's as good as if it were examined by nobody, and any errors in the code are unlikely to be made public.

After the release of PGP 2.6, someone examining the code noticed an error in a random-number generator. The mistake was very minor. A statement that should have been an XOR with operation (~=) was in fact, an assignment (=). The result was that the random number seed was somewhat less random than expected. This didn't seriously compromise the security of PGP, but it did reduce the strength of the random keys.

This error was quickly corrected, and the incident does illustrate some important points. It shows that the code is examined by others and that coding errors (intentional or unintentional) do get spotted. Due to the minor, obscure, nature of this buglette, it also indicates that the probability of a more serious bug or backdoor going undetected is rather low.

Myth 3. Anyone could put a backdoor or trapdoor in open source software.

The simplest response to this is: How? Open source uses source control, it uses code examination and analysis by others, and it puts the personal reputations of the authors on the line. Who would personally risk his or her reputation by putting a backdoor in source that is openly available in public forums?

This can be contrasted with closed source programs, which have an amazing array of "Easter eggs," those cute little surprises programmers leave in their code. What does the existence of such surprises say about the state of code review and source control in closed source circles?

This begs the question: Are there backdoors and serious surprises we can't see? Easter eggs are cute and backdoors aren't. Outside of that, there isn't much difference between them. Placing such secret surprises in open source would certainly seem much more difficult to do, if not a paradox in itself.

Myth 4. Hackers are going to find all the security holes in open source software.

Well, this really isn't a myth. The real myth is that they won't find the security holes in closed source software. One only has to look at the security warnings and advisories attached to any of the closed source systems to realize this. It has become almost a joke in the industry that hackers (good and bad) probably have better debugging, analysis, and reverse-engineering tools than developers have. Unfortunately, this joke often ends up with a decidedly unfunny punch line for network administrators.

The closed source camp likes to point out every open source security advisory as evidence that open source is insecure. In doing so, they conveniently ignore the counter examples in their own advisories. They also conveniently overlook the fact that open source problems are often found and fixed before they're widely exploited, while some closed source problem go unaddressed for months, or longer.

Recently, Alan Cox announced a Solaris security hole on the Bugtraq mailing list, after waiting over a year for Sun to fix the problem. Sun's response: that Alan had failed to notify the "correct people."

In contrast, the "Ping 'O Death" bug was fixed in Linux only a few hours after it was announced. The same bug remained unsolved in some closed source systems for weeks or months. The author of the "teardrop" exploit only released its source after seeing David Miller commit the fix to the Linux source tree.

Information Security Magazine: Open-Source Security - Open Source Under The Hood(Mar 25, 2001)
SFGate: The Spy Who Hacked Me: Will Open Source Be The Hero Of International Security?(Mar 15, 2001)
VNU Net: US security agency (NSA) eyes open source(Feb 02, 2001)
LinuxWorld: Open source closes backdoors - Security through code obscurity provides false confidence(Nov 12, 2000)
SecurityFocus.com: Falling Apart at the Seams [Security and Open Source](Sep 05, 2000)
Open Source IT: The Myth of Open Source Security(May 26, 2000)
Security Portal: Open Source - Why it's Good for Security(Apr 18, 2000)
SecurityFocus.com: Wide Open Source - Is Open Source really more secure than closed?(Apr 17, 2000)

[Mar 31, 2001] developerWorks Linux The security implications of open source software

Theory vs. practice
Still, there are skeptics. "Simply being open source is no guarantee of security," says Craig Willis, computer consultant and a state government systems analyst. "Just as the good guys are looking for vulnerabilities, the same thing goes for the bad guys. 'Security through obscurity' may not be something you should depend on, but it can work to your advantage if the attacker can find an easier target."

Lee Badger, principal computer scientist at Network Associates, agrees, countering that the many-eyes theory "assumes people are motivated to examine even the mundane code -- and I'm not sure that's the case."

Even a few open source advocates admit the dilemma. The author of the GNU mailing list manager Mailman, John Viega, revealed that for three years Mailman had a handful of glaring security code problems, yet no one caught or reported the errors. The version of Mailman that contains these security holes was downloaded thousands of times and even included in Red Hat Professional Linux version 6.2 until mid-2000. Apparently, says Viega, everyone using Mailman assumed that someone else had done the proper security auditing, when in fact, no one had.

Says Viega, "The benefits open source provides in terms of security are vastly overrated, because there isn't as much high-quality auditing as people believe, and because many security problems are much more difficult to find than people realize."

Viega points out that even after they were identified, the security problems in Mailman took many months to fix, partly because it was written in Python (rather than the more popular C) and partly because security was not the core development team's immediate concern.

Viega lists several things that can discourage people from reviewing source code, including code that looks "like a tangled mess," or programs written in a lesser-used language. Another deterrent is human nature, as most programmers look at source code for their own benefit, not for altruistic motivations.

One issue some detractors cite is that open source code is only as good as the skill of those who review it. "Many (developers) don't understand enough to avoid problems beyond the handful of dangerous calls they know," says Viega. According to his article on open source myths (see Resources later in this article), it is common for developers to use cryptography, but misapply it in ways that destroy the security of the system, or to use encryption that is too weak and can easily be broken. Another mistake is for developers to try to hand roll their own protocols using common cryptographic primitives, not fully understanding that cryptographic protocols are generally more complex than expected and easy to get wrong.

Theo de Raadt, project leader for the open source operating system OpenBSD, is another who doubts the safety net of peer review. "These open source eyes that people are talking about -- who are they?" de Raadt asks. "Most reviewers of open source code are amateurs. Most of them, if you asked them to send you some code they had written, the most they could do is 300 lines long," he says. "They're not programmers."

Another complaint with open source software is that most bugs are found after the program has been compiled, tested, and distributed -- not because someone sat down in advance and looked at the code for holes, but because something goes wrong in its use. With a few exceptions, open source programs do generally rely on user reports and public forums to find vulnerabilities.

Resources

• Read John Viega's article "Open source software: Will it make me secure?" in developerWorks' Security special topic.
• Follow the latest security news at SecurityFocus.com's BugTraq.
• Understand the ins and outs of OSS at the Open Source Initiative Web site.
• Read the Ping o' Death Diary.

Linux Today - ABC News Linux Sux Redux; The Open-Source Platform Is Open to a Slew of Vulnerabilities

But now comes news from BugTraq that gives the lie to the widely held belief that Linux is any less vulnerable than its competitors. Linux's known weaknesses turn out to be proliferating faster than its market share. BugTraq publishes "Vulnerability Database Statistics" (a list of bugs, essentially, that are discovered each year in various software products) that demonstrate rather dramatically how determined Linux is to join the Big Leagues -- if not necessarily in market share, then in what might be called "vulnerability share."

SRO: And The Loser Is ... [Bugtraq Record on MS Security](May 16, 2000)
SecurityFocus.com: Wide Open Source - Is Open Source really more secure than closed?(Apr 17, 2000)
dot-lies.com Counters Microsoft's dot-truth.com FUD(Mar 10, 2000)
Eric Lee Green: FUD101 At One Year Old(Dec 02, 1999)
Linux Today Counter-FUD Work Reveals 'World Domination' in Progress(Dec 02, 1999)
ABC News: Charge of the Linux Brigade(Nov 23, 1998)

PC Week: Experts debate merits of open source for security (Mar 24, 2000)
Security Portal: An overview of OS security features - part I (Mar 22, 2000)
Security Portal: DDOS attacks' ultimate lesson: Secure that infrastructure (Mar 20, 2000)
Silicon.com: Linux is a security risk, experts claim (Mar 20, 2000)
Network Computing: Best Practices in Network Security (Mar 18, 2000)
TechWeb: Task Force: Internet Security Holes Rampant (Mar 16, 2000)
SecurityFocus.com: The Coming Linux Plague (Mar 13, 2000)
LinuxSecurity.com: Intrusion Detection Primer (Mar 13, 2000)
PC Week: PentaSafe aims to plug OS security holes (Mar 09, 2000)
SJ Mercury/Reuters: Software industry blasted for security lapses (Mar 09, 2000)
SRO: Microsoft's Not The Only Security Foul-Up (Mar 09, 2000)
Security Portal: UNIX (and Linux especially) viruses - the real story (Mar 08, 2000)
Network Magazine: Building a Robust Linux Security Solution (Mar 07, 2000)
security focus: Security Whitepaper: Seeds may already be sown for worse attacks (Mar 01, 2000)

anon - Subject: Moody is absolutely correct! ( Aug 2, 2000, 17:11:50 )

Face it folks, the prime platforms for attacks by script kiddies are linux boxes, and that is only because there are more linux boxes in the hands of home users who run unnecessary networking services than other unixes. Since any linux box can be a server (most Windows boxes can't) any linux box makes a juicy target for those seeking to host illicit IRC channels or ddos attack bots, or simply to use as intermediate nodes to obfuscate the cracker's identity while sniffing more lucrative commercial unix servers and networks. Frankly, unix security sucks. It's real purpose is to provide job security for unix sysadmins, who can *sometimes* secure unix networks after they have learned the ropes and arcane, non-documented secrets passed on in the boys club that is uniquely unix like nothing else. Specifically, most linux distros start far too many networking services by defaut and provide the user with no useful or sensible documentation on how to reduce security risks. Since crackers can't log onto most windows boxes remotely, they attack Windows by playing on the vulnerabilities of vb scripting, js, and active x, but ONLY if the user does stupid things or allows these scripting hosts to run while web browsing in unknown territory or reading email. I think that linux needs to re-examine the unix security model. Not only does it suck, but is stinks. It can be improved, and even simplified. Alternate metods of establishing and verifying users should be considered. Unix has failed miserably in providing the needed level of security even with highly paid sysadmins on board in major corporations. I'm not saying that any other system has better security, on balance, but the main impediment to creative development of better security for unix is the old boy network of grossly overpaid and mostly incompetent sysadmins who trade on arcane knowledge passed on to insiders rather than real skills, as are required by those who develop rather than just administer. Let the developers establish a security model that can be easily handled by home users running simple local networks or none at all, and is flexible enough for use with large networks as well. Get the sysadmins out of the business of establishing security with arcane scripts.

Ganesh Prasad - Subject: Feedback to ABC News ( Aug 3, 2000, 00:25:55 )

I sent this feedbeck to ABC News http://www.abcnews.go.com/service/Help/abc_contactus.html regarding Fred Moody's column "Linux Sux Redux" http://www.abcnews.go.com/sections/tech/FredMoody/moody.html Dear Sirs, I have a lot of respect for ABC News, but it should concern you that your credibility is being undermined by journalists who write biased pieces under your banner. The journalist I refer to is Fred Moody, who has recently written a piece called Linux Sux Redux. I eagerly read the article to understand the security vulnerabilities that Moody claims are far more serious than in comparable operating systems. Being a Linux user for a few years now, I needed to know those vulnerabilities. To my disappointment, I found that the statistics quoted by Moody suffer from double-counting. He has aggregated bug statistics of various Linux distributions, counting many bugs twice, and making it look like Linux is less secure than Windows NT, rather than the other way around. I was surprised at why he did this, until I read on LinuxToday that he is a former Microsoft employee. I think in the interests of maintaining journalistic integrity as well as the normally high level of credibility associated with ABC News, you should prominently disclose all items such as Moody's past employment that could potentially be conflicts of interest. You should also have articles vetted by independent persons to ensure that blatantly false statistics do not get published. It's very embarrassing to the publication and the journalist when they are discovered and pointed out. Thanking you, Yours sincerely, Ganesh Prasad

Linux Today - SecurityFocus.com Wide Open Source - Is Open Source really more secure than closed

Is Open Source really more secure than closed? Elias Levy says there's a little security in obscurity.
By Elias Levy April 16, 2000 11:59 PM PT

One of the great rallying cries from the Open Source community is the assertion that Open Source Software (OSS) is, by its very nature, less likely to contain security vulnerabilities, including back doors, than closed source software. The reality is far more complex and nuanced.

Advocates derive their dogmatic faith in the implicit security of Open Source code from the concept of "peer review," a cornerstone of the scientific process in which published papers and theories are scrutinized by experts other than the authors. The more peers that review the work, the less likely it is that it will contains errors, and the more likely it is to become accepted.

Open Source apostles believe that releasing the source code for a piece of software subjects it to the same kind of peer review as a quantum physics theory published in a scientific journal. Other programmers, the theory goes, will review the code for security vulnerabilities, reveal and fix them, and thus the number of new vulnerabilities introduced and discovered in the software will decrease over time when compared to similar closed source software.

It's a nice theory, and in the ideal Open Source world, it would even be true. But in the real world, there are a variety of factors that effect how secure Open Source Software really is.

Sure, the source code is available. But is anyone reading it?

If Open Source were the panacea some think it is, then every security hole described, fixed and announced to the public would come from people analyzing the source code for security vulnerabilities, such as the folks at OpenBSD, the Linux Auditing Project, or the developers or users of the application.
 

But there have been plenty of security vulnerabilities in Open Source Software that were discovered, not by peer review, but by black hats. Some security holes aren't discovered by the good guys until an attacker's tools are found on a compromised site, network traffic captured during an intrusion turns up signs of the exploit, or knowledge of the bug finally bubbles up from the underground.

Why is this? When the security company Trusted Information Systems (TIS) began making the source code of their Gauntlet firewall available to their customers many years ago, they believed that their clients would check for themselves how secure the product was. What they found instead was that very few people outside of TIS ever sent in feedback, bug reports or vulnerabilities. Nobody, it seems, is reading the source.

The fact is, most open source users run the software, but don't personally read the code. They just assume that someone else will do the auditing for them, and too often, it's the bad guys.

Even if people are reviewing the code, that doesn't mean they're qualified to do so.

In the scientific world, peer review works because the people doing the reviewing possess a comparable, or higher, technical caliber and level of authority on the subject matter than the author.

It is generally true that the more people reviewing a piece of code, the less likely it is the code will have a security flaw. But a single well-trained reviewer who understands security and what the code is trying to accomplish will be more effective than a hundred people who just recently learned how to program.

It is easy to hide vulnerabilities in complex, little understood and undocumented source code.

Old versions of the Sendmail mail transport agent implemented a DEBUG SMTP command that allowed the connecting user to specify a set of commands instead of an email address to receive the message. This was one of the vulnerabilities exploited by the notorious Morris Internet worm.

Sendmail is one of the oldest examples of open source software, yet this vulnerability, and many others, lay unfixed a long time. For years Sendmail was plagued by security problems, because this monolithic programs was very large, complicated, and little understood but for a few.

Vulnerabilities can be a lot more subtle than the Sendmail DEBUG command. How many people really understand the ins and outs of a kernel based NFS server? Are we sure its not leaking file handles in some instances? Ssh 1.2.27 is over seventy-one thousand lines of code (client and server). Are we sure a subtle flaw does not weakening its key strength to only 40-bits?

There is no strong guarantee that source code and binaries of an application have any real relationship.

All the benefits of source code peer review are irrelevant if you can not be certain that a given binary application is the result of the reviewed source code.

Ken Thompson made this very clear during his 1983 Turing Award lecture to the ACM, in which he revealed a shocking, and subtle, software subversion technique that's still illustrative seventeen years later.

Thompson modified the UNIX C compiler to recognize when the login program was being compiled, and to insert a back door in the resulting binary code such that it would allow him to login as any user using a "magic" password.

Anyone reviewing the compiler source code could have found the back door, except that Thompson then modified the compiler so that whenever it compiled itself, it would insert both the code that inserts the login back door, as well as code that modifies the compiler. With this new binary he removed the modifications he had made and recompiled again.

He now had a trojaned compiler and clean source code. Anyone using his compiler to compile either the login program , or the compiler, would propagate his back doors.

The reason his attack worked is because the compiler has a bootstrapping problem. You need a compiler to compile the compiler. You must obtain a binary copy of the compiler before you can use it to translate the compiler source code into a binary. There was no guarantee that the binary compiler you were using was really related to the source code of the same.

Most applications do not have this bootstrapping problem. But how many users of open source software compile all of their applications from source?

A great number of open source users install precompiled software distributions such as those from RedHat or Debian from CD-ROMs or FTP sites without thinking twice whether the binary applications have any real relationship to their source code.

While some of the binaries are cryptographically signed to verify the identity of the packager, they make no other guarantees. Until the day comes when a trusted distributor of binary open source software can issue a strong cryptographic guarantee that a particular binary is the result of a given source, any security expectations one may have about the source can't be transferred to the binary.

Open Source makes it easy for the bad guys to find vulnerabilities.

Whatever potential Open Source has to make it easy for the good guys to proactively find security vulnerabilities, also goes to the bad guys.

It is true that a black hat can find vulnerabilities in a binary-only application, and that they can attempt to steal the source code to the application from its closed source. But in the same amount of time they can do that, they can audit ten different open source applications for vulnerabilities. A bad guy that can operate a hex editor can probably manage to grep source code for 'strcpy'.

Security through obscurity is not something you should depend on, but it can be an effective deterrent if the attacker can find an easier target.

So does all this mean Open Source Software is no better than closed source software when it comes to security vulnerabilities? No. Open Source Software certainly does have the potential to be more secure than its closed source counterpart.

But make no mistake, simply being open source is no guarantee of security

Linux Today - Open Source IT The Myth of Open Source Security

"An author of the open source Mailman program explains why open source is not as secure as you might think -- using security holes in his own code as an example."

"Open source software projects can be more secure than closed source projects. However, the very things that can make open source programs secure -- the availability of the source code, and the fact that large numbers of users are available to look for and fix security holes -- can also lull people into a false sense of security."

"Eyes that look do not always see
With people motivated to look at the source code for any number of reasons, it's easy to assume that open source software is likely to have been carefully scrutinized, and that it's secure as a result. Unfortunately, that's not necessarily true. "

Slashdot Can Open Source Be Trusted

More than closed source (Score:3, Insightful) by hattig (SpinningNucleon FATBAT yahoo.com) on Friday June 23, @07:29AM EDT (#13) (User Info) http://evil.cones.org.uk/

Open source software can be trusted more than closed source software when it comes to security, for all the reasons that you all know (quicker bugfixes, code open to scrutiny, etc). Closed source software can have hidden APIs, bad implementations and bugs, and the release cycle is slow. OpenBSD is interesting, as they do audits on software to get rid of the security holes. They can only do this because the source code is available. Of course, software like Sendmail, various ftpds, POP3 daemons etc, all mess up the security aspect of an OS. The OS can be as secure as it can possible be whilst still being usable and useful, but if the software being run on it is vulnerable, then backdoors into the system will be found. Having the source code available allows the cracker to find better access methods than having to guess and feel their way into a system. You just have to remember that there will never be perfect security, and plan accordingly.

Amazing - (Score:1, Insightful) by Chris Worth (chris@nospamchrisworth.com) on Friday June 23, @07:29AM EDT (#14) (User Info) http://www.chrisworth.com

I find this amazing - so open source doesn't submit itself well to a closed-doors 'expert review' where the experts are usually appointed through a political process rather than a skills one? Open source's strength is that it's Darwinian. Yes, a program can start off full of holes, but the whole point is that these holes become evident through the development process, and get plugged. Hell, even I get this, and I'm not even a developer/techie. (Read The Microsoft Matrix" to see what I've learned.

It's all in the people... (Score:5, Insightful) by Spoing on Friday June 23, @09:00AM EDT (#119) (User Info)

The following is dry, and opinionated, from the POV of an old-timer VV&T/QT/Tester. I'm big on specifications, and will argue both sides of a contract when a spec is violated. I've even been in a couple shouting matches over them, fighting for the correct implementation, not supposed "flexibility" though they do need to be bent at times. Fortunately, the shouting matches are rare and as a Contractor Scum(tm), I never take them personally...only as a barganing point and to help stiffen the backs of those who are easily swayed. It's a shame when good projects go bad, but that's other people's money! Good specifications are invaluable in eliminating all sorts of conflicts and allow projects to actually end without different groups wanting to kill each other. Unfortunately, specifications are by necessity limited in scope. If it's not in the spec, it can't easily be added. If it's in the spec, it can't be modified easily. On a formal contract, adding in goals like "The system shall be fast" don't work well, so more detail is usually specified; "The system shall retrieve a query on the client stations within 4 seconds at all times". There's always a few details that slip by, and if the people on the project aren't reasonable the details will cause quite a few social and technical problems. Even relying on an outside specification is a problem...since APIs/protocols/... are usually vauge on some level. The people who implement it and the environment have a much greater impact on the results; there will be good and bad free software / open source projects...as there are good and bad commercial projects. From what I've seen, I'll trust open source as much or more in most cases...but I'll test it first.

Specifications are not to be trusted (Score:1) by Diabolical on Friday June 23, @07:31AM EDT (#18) (User Info)

If you can actually PROOF that you adhered to the specs that were outlined eveything is okay.. but as with alot of things people cannot be trusted enough to follow the specs. Just look at constructing. If a wiring scheme inside a building can be much cheaper because of cheaper wires they will put those in.. if a company can save money by NOT adhering to the specs they sure as hell will... if you create some specs and afterwards your product seems to adhere to them that does not mean that internally eveything is correct. At least with Open Source you can check that. Of course he is correct at the point of Linux and most other projects being chaos like. That's inherent to the bazaar model of things.. But strongly run Open Source projects with clearly outlined goals and specifications can be as secure as anything else... Just my thoughts about the subject

Here is an opinion of John Viega, a Senior Research Associate in the Software Security Group at Reliable Software Technologies, an Adjunct Professor of Computer Science at the Virginia Polytechnic Institute, the author of Mailman, the open source GNU Mailing List Manager, and ITS4, a tool for finding security vulnerabilities in C and C++ code. He has authored over 30 technical publications in the areas of software security and testing, and is responsible for finding several well-publicized security vulnerabilities in major network and e-commerce products, including a recent break in Netscape's security. In his recent paper open source resources at open source it The Myth of Open Source Security he wrote:

...Even if you get the right kind of people doing the right kinds of things, you may have problems that you never hear about. Security problems are often incredibly subtle, and may span large parts of a source tree. It is not uncommon to have two or three features spread throughout a program, none of which constitutes a security problem alone, but which can be used together to perform a security breach. For example, two buffer overflows recently found in Kerberos version 5 could only be exploited when used in conjunction with each other.

As a result, doing security reviews of source code tends to be complex and boring, since you generally have to look at a lot of code, and understand it pretty well. Even many experts don't like to do these kinds of reviews.

And even the experts can miss things. Consider the case of the popular open source FTP server wu-ftpd. In the past two years, several very subtle buffer overflow problems have been found in the code. Almost all of these problems had been in the code for years, despite the fact that the program had been examined many times by both hackers and security auditors. If any of them had discovered the problems, they didn't announce it publicly. In fact, the wu-ftpd has been used as a case study for vulnerability detection techniques that never identified these problems as definite flaws. One tool was able to identify one of the problems as potentially exploitable, but researchers examined the code thoroughly for a couple of days, and came to the conclusion that there was no way that the problem identified by their tool could actually be exploited. Over a year later, they learned that they were wrong, when an expert audit finally did turn up the problem.

In code with any reasonable complexity, it can be very difficult to find bugs. The wu-ftpd is less than 8000 lines of code long, but it was easy for several bugs to remain hidden in that small space over long periods of time.

To compound the problem, even when people know about security holes, they may not get fixed, at least not right away. Even when identified, the security problems in Mailman took many months to fix, because security was not the the core development team's most immediate concern. In fact, the team believes one problem still persists in the code, but only in a configuration that we suspect doesn't get used.

An army in my belly

The single most pernicious problem in computer security today is the buffer overflow. While the availability of source code has clearly reduced the number of buffer overflow problems in open source programs, according to several sources, including CERT, buffer overflows still account for at least a quarter of all security advisories, year after year.

Open source proponents sometimes claim that the "many eyeballs" phenomenon prevents Trojan horses from being introduced in open source software. The speed with which the TCP wrappers Trojan was discovered in early 1999 is sometimes cited as supporting evidence. This too can lull the open source movement into a false sense of security, however, since the TCP wrappers Trojan is not a good example of a truly stealthy Trojan horse: the code was glaringly out of place and obviously put there for malicious purposes only. It was as if the original Trojan horse had been wheeled into Troy with a sign attached that said, "I've got an army in my belly!"

...Currently, however, the benefits open source provides in terms of security are vastly overrated, because there isn't as much high-quality auditing as people believe, and because many security problems are much more difficult to find than people realize. Open source programs which appeal to a limited audience are particularly at risk, because of the smaller number of eyeballs looking at the code. But all open source software is vulnerable, and the open source movement can only benefit by paying more attention to security.