Printable View
I would like to know your opinions on whether open source software development leads to better/worse/equivalent security for software projects than closed source software projects and why do you believe it?
** Disclaimer - this is not to turn into a flame war. I want opinions and I want it backed up by some kind of fact if possible. This thread is meant to make you think and I will be putting up counter arguments for all sides if possible.**
The way I see it, open source allows everyone to look at the code and find the problems in it rather easily. They can then exploit it or explain how to fix it. Closed source on the other hand requires that a person pokes around trying to break it, until they eventually find a bug. Then its upto the developers to fix it, nobody else has any say in that matter.
<brain fart> i'll finish this when I'm able to word it right </brain fart>
The critical thing here is that in fact, only developers ever do look at the code. In both a closed source and open sourced environment your code reviews will be done by developers only. You have two considerations to take into account in comparing the two: Number of experienced eyes sifting through the code before committing it to the source tree, and accessibility of the code to those who would do your project harm (or exploit vulnerabilities, etc).Quote:
Originally posted here by Darksnake
The way I see it, open source allows everyone to look at the code and find the problems in it rather easily. They can then exploit it or explain how to fix it. Closed source on the other hand requires that a person pokes around trying to break it, until they eventually find a bug. Then its upto the developers to fix it, nobody else has any say in that matter.
IMHO, the benefits of open sourced programming are canceled out by the fact that in addition to the developers of a project, crackers/hackers/etc also have access to the source code. In both situations it expedites bug finding and patching, and vulnerability finding and exploitation for both sides of the fence.
A closed source environment may offer more bugs, and yet it will take an equally determined attacker longer to find them due to the closed nature of the code. The attacker in the instance of closed source software is relegated to trial and error, whereas in the instance of open source software, a skilled cracker/hacker can sift through the code itself, and can get a picture of how it works, then from there much more quickly discover vulnerabilities.
It's a very tough call to have to call one or the other. To an end user, I imagine open sourced software would seem to be much more adaptive and quick in responding to vulnerabilities with patches, however I do think people should stop comparing all of OSS to just Microsoft. Microsoft has a bad track record, yes. What about Novell with Netware? Or Apple with MacOS? Adobe and their line of products? Many closed source companies are indeed capable of developing lines of secure software just as well as open sourced ones.
As I said, tough choice. For me, it would depend on the nature of the project, and when security is the overriding question at the heart of the matter, I do not believe they are functionally different. Theoretically, and given time, sure, open source software has the edge in the sheer number of people reviewing the code. Functionally however, I would venture to say that the rate of bug exposing and vulnerability exploitation resulting from both development types is roughly even.
I believe, like Operating Systems, they both suck equally but for different reasons.
Closed source development projects, while they do not get the number of eyes on the source code doing auditing from a white box perspective (auditing/testing with source), get great numbers of people doing testing and auditing from a black box perspective (without source). It is common for companies generating this type of software to have code reviews by the developers, testing and auditing from black and white box perspectives by a Quality Assurance team, possible testing and auditing by outside contractors, and a good possibility of the source being run through an assortment of tools for regression testing, code analysis (complexity, security, etc), and so on.
It will also most likely be beta tested for some time by any number of users and finally released to the public which will also use the product. There will be a good number of people who will audit the programs security from a black box perspective to see if it suits their needs, and another good portion that will look for holes to exploit maliciously or to make a name for themselves. Holes found may get reported, may get ignored, or might be held back for malicious purposes as long as possible.
It would be nice if when doing these audits the source code was available so that you may hit it from a white box perspective and piece together what is going on. Maybe even fix the problem or report it to the vendor. It definitely beats watching crash messages to see if your buffer overflow idea worked or not. Hell, you could even run a source analysis tool against it and have a chance of picking it up right away (though they don't always catch the problem).
Open source on the other hand has the possibility for thousands if not millions of people to audit the source code. The biggest problem however, is that you have to hope that people did their due dilligence in planning the security, testing, auditing, etc of your applications before pushing them out. While you have to hope the same thing happened on the closed source team, no one's job is on the line for the open source team to do it. This has been the cause of problems in the past when one team member expects another to do it and vice versa...and it doesn't get done.
While you may expect companies such as Red Hat to spend a little cash or time to audit the applications they include with their distributions, that doesn't always happen (or rarely if ever) and has nailed them in the past as well. Finally as chsh stated, you may have quantity (stressing may) but that doesn't guarantee quality of the reviewer. Generally the source will be reviewed by someone who has something to gain from it.
It will be done by malicious people who are looking for holes to exploit, by individuals at companies who are looking to see if it fits their needs, by people looking to make a name for themselves, or by people who get paid for it. Rarely will most users do an in depth audit of the architecture, language quirks (dangerous functions, poorly implemented language/platform security measures), algorithms, testing of component interaction, etc. Relatively few users of any system have the requisite skills to even attempt it.
Some issues surface relatively quickly however and a patch for the problem is posted in a short amount of time. Not all open source projects have these issues, but the problem does exist.
My reading, research and experience is pointing me to believe what chsh said. The rate of bug exposing and vulnerability exploitation resulting from both dev types is roughly even.
I think the real issue of security lies in what is being protected. For example the majority of boxes attacked on the internet are web servers, web servers on the internet are mostly Apache on Linux. For that reason most web servers that are attacked are Linux boxes. On the other hand user boxes are overwhelmingly windows. And for that reason most of your viruses and worms go after these. As has been stated on this site before nothing is secure, those who chose to go after something will go after something they are familiar with, be it web servers, Databases, E-mail clients Etc... The more market penetration a product has the "Less secure" it will be because one exploit or vulnerability will proliferate so much more. And there is also the problem of trying to get larger numbers to update/patch so it will remain so for longer.
Just my thoughts
A valid point. However, what I'm trying to do here is promote discussion on whether one style of project leads to more secure development being done than the other, and why do people believe it to be that way?
As chsh has stated before....
Linux != all opensource development && Windows != all closed source development
with closed source you need one source to provide you with the fix, while in open source any one could even your self.
anyways you migh want to read "The cathedral and the bazaar" paper to know the goods and bads of each.
I thought that this was a really interesting look at some of the common myths that surround Open Source Development. Might be worth a look.
http://www.onlamp.com/pub/a/onlamp/2.../11/myths.html
I think this largely depends on the shop and the product concerned, as this directly affects how the developement team considers the importance of having secure code, regardless of whether its open source or not.Quote:
However, what I'm trying to do here is promote discussion on whether one style of project leads to more secure development being done than the other, and why do people believe it to be that way?
-Maestr0
For 'the cathedral and the bazaar' information you can go to - http://www.catb.org/~esr/writings/cathedral-bazaar/
VicC > interesting link. I'm going to post some of the myths they bring up here:
Myth: Publicly releasing open source code will attract flurries of patches and new contributors.
Reality: You'll be lucky to hear from people merely using your code, much less those interested in modifying it.
Myth: New developers interested in the project will best learn the project by fixing bugs and reading the source code.
Reality: Reading code is difficult. Fixing bugs is difficult and probably something you don't want to do anyway. While giving someone unglamorous work is a good way to test his dedication, it relies on unstructured learning by osmosis.
Myth: Installation and configuration aren't as important as making the source available.
Reality: If it takes too much work just to get the software working, many people will silently quit.
Myth: Even though your previous code was buggy, undocumented, hard to maintain, or slow, your next attempt will be perfect.
Reality: If you weren't disciplined then, why would you be disciplined now?
Myth: Users don't mind upgrading to the latest version from CVS for a bugfix or a long-awaited feature.
Reality: If it's difficult for you to provide important bugfixes for previous releases, your CVS tree probably isn't very stable.
These are only a few of the points brought up in the article VicC posted (for those of you who didn't read it) and are all valid arguments. I'd say anyone who hasn't taken a peek at it already probably should.
qod > I agree. Waiting for a fix from a closed source vendor is a pain. Open source projects are indeed nice since you can get fixes from multiple sources, or even do it yourself. I would throw the quality of the code being pushed into question however. If you are getting fixes from others I would make doubly sure that the code you're getting is safe to run, and verify that it fixes the problem and doesn't compromise the functionality of the system elsewhere. Depending on the scope of the problem it is possible for educated users to fix something themselves. Also depending on the issue this could open other holes due to a less than thorough understanding of what is being done or the system as a hole. If these projects had a thorough set of automated test scripts (and some do) to run for regression testing purposes I think I'd feel a bit better.
I personally think there's not a lot in it.
Being a web developer, I've seen a lot of web application source code - closed source as well as open source.
While it's true that the security of the application depends very much on the methodology and technology, I don't think whether it's open or closed makes a great deal of difference.
I've seen the same lame bugs come up again and again, in open and closed source alike, SQL injection for example.
There have been ample SQL injections in M$'s web application code (typically using ASP), and quite a lot also in open source stuff, like phpbb.
I think that some OSS projects though, like Linux, have extremely high standards.
Linux is one of the best ones, unfortunately nearly every else (OSS and otherwise) is a long way behind. REALISTICALLY, in many OSS projects, there are only a few developers, and they rarely, if ever, review one anothers' code.
In most cases, it's possible to get into an OSS group merely by sounding enthusiastic and competent. It's commonplace to hand out CVS commit access to total strangers.
Of course, Linux is an extreme example, its hierarchical peer review system ensures that every piece of code is either written by, or approved by, someone who Linus trusts a lot, and in most cases has met.
Slarty
Ah yes, the good old OS vs CS discussion. Don't worry, I'm not here to rain on parades, hehe...
Open Source pros - easier to create stable environments because you have the masses to report issues, improve, optimize and trim down code, and have faster response times for fixes because there's forums for just about everything OS-related.
Open Source cons - you have no idea where your code's going, you have to make sure it's held together by something like Sourceforge so all official work is tracked, you want to ensure there's one 'stable' release tree in CVS as well as multiple 'development, try on your own' trees that are not mixed, people can alter it at will and never tell you, and of course, bugs can be found and exploited and never reported but that's harder to do because if one finds it and never tells, another will find it and probably will tell.
Closed Source pros - easy to maintain one official release of code with all sorts of legal jargon meant to scare people who wish to 'decompile' the code and figure out how it works, one central location will house the source code ensuring physical security, and overall is easy to maintain.
Closed Source cons - everything relies on the developers actually FIXING something that's reported. Many times I've seen bugs go ignored for weeks because the developers are too swamped with work on other issues. This isn't good. In OS you can SEE a fix, improve upon it, actually fix it if it's not working up to par, etc. You can't do this as a CS program user. Begging, pleading, cussing out, flaming, etc will be useless because developers respond to those about as much as game developers respond to forum questions concerning release dates. Then you have the one developer who really gives a **** and tries to respond and once the masses see this person as wanting to help, they immediately flood him/her with "Fix this, fix that, this is broken, this needs help", etc. Not to their fault, but because they have someone that's TALKING to them. Companies with closed source generally have VERY tight rules on what's said relating to their product, especially concerning new releases, bug fixes, and the like. Customer support is an inherent problem, as you can see. Companies like MS "say" something's fixed, but because we have no way of knowing whether it's true, we have to TRUST them, and since it's been proven time and time again that other issues have popped up, etc...it becomes a lesson in futility and one I'd like to stay away from.
IMHO, I'm all for Open Source. I've worked on 3 MUDs and the open-source nature of it has allowed people to see my work, offer improvements, etc. We all learned to share in kindergarten, so why not pass that along to the real world of programs? Sure, there are people out there that do nothing more than exploit bugs, create problems, and overall abuse the entire system, but the general populous is a "Do the right thing" group and that's where your benefits go to as well as come from. Closed source offers certain things that Open source can't....but the benefits from OS, IMHO, far outweigh these few things.
OS for life, baby!