Open-source misperceptions live on

The enterprises, vendors, developers, analysts, and journalists I speak with regularly are mostly pretty savvy about the basics of open source at this point. Even if they're not licensing geeks or otherwise expert in all the minutiae and subtle implications of open-source development, community, and usage, they generally have the important basics down.

However, as I read Rice University computer science professor Dan Wallach's detailed and thorough critique of an Election Technology Council white paper on open source in voting systems, I'm reminded that there are still a lot of misperceptions about open source among the broader public.

A lot of people are quick to dismiss such confusion as evidence of sinister plots to deliberately undermine open source. No doubt, some is indeed willful misunderstanding, or simply disinformation.

But certainly not all. I've personally heard longtime friends from outside the tech industry voice many of the same beliefs. Many of these fall into one of two buckets: open-source software depends on the support of some nebulous "community," and open-source is less secure because bad guys can use the code to find vulnerabilities.

With respect to the first point, this discussion in the ETC paper is typical:

Due to the volunteer nature of an open source model, the issue of accountability in this environment provides a stark contrast to the accountability within a traditional proprietary offering. In commercial product offering, the individual company is held accountable for delivering a product that meets all applicable standards and for meeting project milestones. Contract requirements are often used to establish performance milestones and clearly delineate the responsibilities of a provider. Within a corporate structure, liability is clearly delineated to the company. In an open source environment, a volunteer group of collaborators will not be so clearly subject to financial liability or have a clear line of accountability. It is possible that a hybrid approach could be undertaken for an open source project which is launched in partnership with a private company, but the issue of intellectual property investment and concerns over the long-term viability of the company's product will likely trigger a need to adopt a more restrictive licensing approach, one more indicative of a traditional proprietary model.

In part, this is a case of conflating open source of circa 1997 or so with open source of 2009. It also reflects that most of the people who are loudest about open source as a social movement emphasize hobbyist communities rather than corporate sponsorship and in-house professional development. Indeed, these people often decry the latter as a betrayal of free-software principles.

The reality for most commercially important projects is much different. The bulk of the development is directly funded by IT vendors for self-interested reasons. In the case of the Linux kernel, the work is shared by a large number of companies. Other software, such as JBoss and MySQL, are primarily worked on by developers at a single company.

Support for major open-source software is similarly commercialized. Although "community support" (that is, forums, blogs, Twitter, etc.) may often in fact be pretty good mechanisms to track down fixes, they're not the only one. A Red Hat Enterprise Linux customer, for example, can get support in exactly the same way that someone with a support contract for Microsoft Windows would.

As for the security question, I look at it largely as a case of analogies gone bad. Typical is this line from a paper on Linux security by a public policy expert that I was asked to review a few years back: "it would seem to stand to reason that if keeping passwords, access numbers, and other aspects of system security secret, keeping code secret might be one way to enhance security."

It all sounds reasonable. After all, even if I think I have a solid security system installed in my office I don't stick its specifications and layout on a piece of paper and nail it to my front door.

However, as Wallach notes:

What we learned from the California Top-to-Bottom Review and the Ohio EVEREST study was that, indeed, these systems are unquestionably and unconscionably insecure. The authors of those reports (including yours truly) read the source code, which certainly made it easier to identify just how bad these systems were, but it's fallacious to assume that a prospective attacker, lacking the source code and even lacking our reports, is somehow any less able to identify and exploit the flaws. The wide diversity of security flaws exploited on a regular basis in Microsoft Windows completely undercuts the ETC paper's argument. The bad guys who build these attacks have no access to Windows's source code, but they don't need it. With common debugging tools (as well as customized attacking tools), they can tease apart the operation of the compiled, executable binary applications and engineer all sorts of malware.

In short, access to software (whether open source or just disclosed source) is not the unlocked door that many non-developers assume it is.

Cryptography provides another example. The mechanisms used by most protocols to encrypt and decrypt data are well-documented. They don't depend on secrecy to work. They depend on an untenable amount of computational power being required to decrypt in the absence of private keys.

And the converse offers further proof. Weak encryption algorithms that depend largely on secrecy are often compromised relatively easily; the Content Scramble System (CSS) used on DVDs is a textbook example.

I take all this as a reminder: don't assume things that "everyone knows" really are.

[sythara]

Great article

[pentest]

Nicely done.

To go further, code review will find some vulnerabilities, but you will never exploit it based on source code. If you don't use the exact compiler and flags, your executable may be too different than what is running on a target to properly exploit.

Most vulnerabilities these days are found via fuzzing or disassemblers, not reading through source code.

[mbenedict]

As a security professional, the biggest problem I see with most open-source projects is the lack of formal security design, review, and testing as part of the project's normal development lifecycle.

Without proper processes in place, security is only based on "hope" that someone from this "nebulous community" will notice a vulnerability. That's simply not a good approach. We keep plugging the same holes over and over again because security was never considered as part of the program's original design.

I don't want to single out particular open-source companies, but let's just say the kinds of continued security breaches we're seeing in many "content management systems" is just mind-boggling and inexcusable. These companies should spend some of their revenue dollars towards improving security rather than leaving their customers (and their community) vulnerable.

[ghaff]

Yes, although that's basically a comment on ad hoc development in general as opposed to open source. There's certainly a correlation between the two--given that so many casual/hobbyist/etc. development projects these days are open source--but it's in no way inherent to open source. Based on looking at open source CMS a couple of years back I can imagine that being a particular problem; it's an incredibly littered landscape with a lot of forked and semi-abandoned projects. (But there are also commercial entities such as Alfresco.)

[vikinzer]

This goes back to the comment made in the article about open source circa 1997. No one in their right mind would deploy a community only open source project in an environment that requires security. You mention specific companies. This is a case of a company producing a poor product. It is the same situation Microsoft had back in the 90's when I could sneeze on their operating system and find a hole in it. That was a closed source situation. This phenomenon has nothing to do with open or closed source. If you are looking at the companies that have built a strong reputation for themselves such as Red Hat, Novell, MySQL(Sun), you see that the development model is neutral in terms of security.

A perfect example of this is Firefox and IE. Firefox has it's share of security problems. I will not say it is more secure than IE inherently. However, IE languished in security squalor for years because Microsoft had so much market share they felt no need to work on the product. Then along comes Firefox, which brands itself as much more secure. In fact it wasn't but no one had written malware for it. Microsoft gets off their behind and patched up IE. It's still not perfect, but it's much improved. Once equillibrium was met we started seeing holes in Firefox, but they were patched very quickly. We still occasionally see Microsoft patch a hole that affects IE going back several full version points. That means the hole has languished un-noticed and un-touched. This is a perfect example of how closed source has it's security problems from lack of oversight from the customer. You're complaint about "open source" having problems because of lack of organization within a "nebulous community" is left void by the fact that you then turn around and point to companies with products. That is the same situation as IE 6. Poor motivation and security processes in a company. Either due to lack of expertise, or lack of motivation.