Slashdot Mirror
The Myth of Open Source Security Revisited v2.0
Dare Obasanjo contributed this followup to an article entitled The Myth of Open Source Security Revisited that appeared on the website kuro5hin. He writes: "The original article tackled the common misconception amongst users of Open Source Software(OSS) that OSS is a panacea when it comes to creating secure software. The article presented anecdotal evidence taken from an article written by John Viega, the original author of GNU Mailman, to illustrate its point. This article follows up the anecdotal evidence presented in the original paper by providing an analysis of similar software applications, their development methodology and the frequency of the discovery of security vulnerabilities." Read on below for his detailed analysis, especially relevant with the currency of security initiatives in the worlds of both open- and closed-source software.
Apples, Oranges, Penguins and Daemons
When performing experiments to confirm a hypothesis on the effect of a particular variable on an event or observable occurence, it is common practice to utilize control groups. In an attempt to establish cause and effect in such experiments, one tries to hold all variables that may affect the outcome constant except for the variable that the experiment is interested in. Comparisons of the security of software created by Open Source processes and software produced in a proprietary manner have typically involved several variables besides development methodology.
A number of articles have been written that compare the security of Open Source development to proprietary development by comparing security vulnerabilities in Microsoft products to those in Open Source products. Noted Open Source pundit, Eric Raymond wrote an article on NewsForge where he compares Microsoft Windows and IIS to Linux, BSD and Apache. In the article, Eric Raymond states that Open Source development implies that "security holes will be infrequent, the compromises they cause will be relatively minor, and fixes will be rapidly developed and deployed." However, upon investigation it is disputable that Linux distributions have less frequent or more minor security vulnerabilities when compared to recent versions of Windows. In fact the belief in the inherent security of Open Source software over proprietary software seems to be the product of a single comparison, Apache versus Microsoft IIS.
There are a number of variables involved when one compares the security of software such as Microsoft Windows operating systems to Open Source UNIX-like operating systems including the disparity in their market share, the requirements and dispensations of their user base, and the differences in system design. To better compare the impact of source code licensing on the security of the software, it is wise to reduce the number of variables that will skew the conclusion. To this effect it is best to compare software with similar system design and user base than comparing software applications that are significantly distinct. The following section analyzes the frequency of the discovery of security vulnerabilities in UNIX-like operating systems including HP-UX, FreeBSD, RedHat Linux, OpenBSD, Solaris, Mandrake Linux, AIX and Debian GNU/Linux.
Security Vulnerability Face-Off
Below is a listing of UNIX and UNIX-like operating systems with the number of security vulnerabilities that were discovered in them in 2001 according to the Security Focus Vulnerability Archive. AIX 10 vulnerabilities[6 remote, 3 local, 1 both] Debian GNU/Linux 13 vulnerabilities[1 remote, 12 local] + 1 Linux kernel vulnerability[1 local] FreeBSD 24 vulnerabilities[12 remote, 9 local, 3 both] HP-UX 25 vulnerabilities[12 remote, 12 local, 1 both] Mandrake Linux 17 vulnerabilities[5 remote, 12 local] + 12 Linux kernel vulnerabilities[5 remote, 7 local] OpenBSD 13 vulnerabilities[7 remote, 5 local, 1 both] Red Hat Linux 28 vulnerabilities[5 remote, 22 local, 1 unknown] + 12 Linux kernel vulnerabilities[6 remote, 6 local] Solaris 38 vulnerabilities[14 remote, 22 local, 2 both] From the above listing one can infer that source licensing is not a primary factor in determining how prone to security flaws a software application will be. Specifically proprietary and Open Source UNIX family operating systems are represented on both the high and low ends of the frequency distribution.
Factors that have been known to influence the security and quality of a software application are practices such as code auditing (peer review), security-minded architecture design, strict software development practices that restrict certain dangerous programming constructs (e.g. using the str* or scanf* family of functions in C) and validation & verification of the design and implementation of the software. Also reducing the focus on deadlines and only shipping when the system the system is in a satisfactory state is important.
Both the Debian and OpenBSD projects exhibit many of the aforementioned characteristics which help explain why they are the Open Source UNIX operating systems with the best security record. Debian's track record is particularly impressive when one realizes that the Debian Potato consists of over 55 million lines of code (compared to RedHat's 30,000,000 lines of code).
The Road To Secure Software
Exploitable security vulnerabilities in a software application are typically evidence of bugs in the design or implementation of the application. Thus the process of writing secure software is an extension of the process behind writing robust, high quality software. Over the years a number of methodolgies have been developed to tackle the problem of producing high quality software in a repeatable manner within time and budgetary constraints. The most successful methodologies have typically involved using the following software quality assurance, validation and verification techniques; formal methods, code audits, design reviews, extensive testing and codified best practices.
Issues Preventing Development of Secure Open Source Software
One of the assumptions that is typically made about Open Source software is that the availability of source code translates to "peer review" of the software application. However, the anecdotal experience of a number of Open Source developers including John Viega belies this assumption.
The term "peer review" implies an extensive review of the source code of an application by competent parties. Many Open Source projects do not get peer reviewed for a number of reasons including
Benefits of Open Source to Security-Conscious Users
Despite the fact that source licensing and source code availability are not indicators of the security of a software application, there is still a significant benefit of Open Source to some users concerned about security. Open Source allows experts to audit their software options before making a choice and also in some cases to make improvements without waiting for fixes from the vendor or source code maintainer.
One should note that there are constraints on the feasibility of users auditing the software based on the complexity and size of the code base. For instance, it is unlikely that a user who wants to make a choice of using Linux as a web server for a personal homepage will scrutinize the TCP/IP stack code.
References
Acknowledgements
The following people helped in proofreading this article and/or offering suggestions about content: Jon Beckham, Graham Keith Coleman, Chris Bradfield, and David Dagon. © 2002 Dare Obasanjo
The Myth of Open Source Security Revisited v2.0 The purpose of this article is to expose the fallacy of the belief in the "inherent security" of Open Source software and instead point to a truer means of ensuring the quality of the security of a piece software is high.
Apples, Oranges, Penguins and Daemons
When performing experiments to confirm a hypothesis on the effect of a particular variable on an event or observable occurence, it is common practice to utilize control groups. In an attempt to establish cause and effect in such experiments, one tries to hold all variables that may affect the outcome constant except for the variable that the experiment is interested in. Comparisons of the security of software created by Open Source processes and software produced in a proprietary manner have typically involved several variables besides development methodology.
A number of articles have been written that compare the security of Open Source development to proprietary development by comparing security vulnerabilities in Microsoft products to those in Open Source products. Noted Open Source pundit, Eric Raymond wrote an article on NewsForge where he compares Microsoft Windows and IIS to Linux, BSD and Apache. In the article, Eric Raymond states that Open Source development implies that "security holes will be infrequent, the compromises they cause will be relatively minor, and fixes will be rapidly developed and deployed." However, upon investigation it is disputable that Linux distributions have less frequent or more minor security vulnerabilities when compared to recent versions of Windows. In fact the belief in the inherent security of Open Source software over proprietary software seems to be the product of a single comparison, Apache versus Microsoft IIS.
There are a number of variables involved when one compares the security of software such as Microsoft Windows operating systems to Open Source UNIX-like operating systems including the disparity in their market share, the requirements and dispensations of their user base, and the differences in system design. To better compare the impact of source code licensing on the security of the software, it is wise to reduce the number of variables that will skew the conclusion. To this effect it is best to compare software with similar system design and user base than comparing software applications that are significantly distinct. The following section analyzes the frequency of the discovery of security vulnerabilities in UNIX-like operating systems including HP-UX, FreeBSD, RedHat Linux, OpenBSD, Solaris, Mandrake Linux, AIX and Debian GNU/Linux.
Security Vulnerability Face-Off
Below is a listing of UNIX and UNIX-like operating systems with the number of security vulnerabilities that were discovered in them in 2001 according to the Security Focus Vulnerability Archive. AIX 10 vulnerabilities[6 remote, 3 local, 1 both] Debian GNU/Linux 13 vulnerabilities[1 remote, 12 local] + 1 Linux kernel vulnerability[1 local] FreeBSD 24 vulnerabilities[12 remote, 9 local, 3 both] HP-UX 25 vulnerabilities[12 remote, 12 local, 1 both] Mandrake Linux 17 vulnerabilities[5 remote, 12 local] + 12 Linux kernel vulnerabilities[5 remote, 7 local] OpenBSD 13 vulnerabilities[7 remote, 5 local, 1 both] Red Hat Linux 28 vulnerabilities[5 remote, 22 local, 1 unknown] + 12 Linux kernel vulnerabilities[6 remote, 6 local] Solaris 38 vulnerabilities[14 remote, 22 local, 2 both] From the above listing one can infer that source licensing is not a primary factor in determining how prone to security flaws a software application will be. Specifically proprietary and Open Source UNIX family operating systems are represented on both the high and low ends of the frequency distribution.
Factors that have been known to influence the security and quality of a software application are practices such as code auditing (peer review), security-minded architecture design, strict software development practices that restrict certain dangerous programming constructs (e.g. using the str* or scanf* family of functions in C) and validation & verification of the design and implementation of the software. Also reducing the focus on deadlines and only shipping when the system the system is in a satisfactory state is important.
Both the Debian and OpenBSD projects exhibit many of the aforementioned characteristics which help explain why they are the Open Source UNIX operating systems with the best security record. Debian's track record is particularly impressive when one realizes that the Debian Potato consists of over 55 million lines of code (compared to RedHat's 30,000,000 lines of code).
The Road To Secure Software
Exploitable security vulnerabilities in a software application are typically evidence of bugs in the design or implementation of the application. Thus the process of writing secure software is an extension of the process behind writing robust, high quality software. Over the years a number of methodolgies have been developed to tackle the problem of producing high quality software in a repeatable manner within time and budgetary constraints. The most successful methodologies have typically involved using the following software quality assurance, validation and verification techniques; formal methods, code audits, design reviews, extensive testing and codified best practices.
-
Formal Methods: One can use formal proofs based on mathematical
methods and rigor to verify the correctness of software algorithms. Tools
for specifying software using formal techniques exist such as VDM and Z.
Z (pronounced 'zed') is a formal specification notation based on set
theory and first order predicate logic. VDM stands for "The Vienna
Development Method" which consists of a specification language called
VDM-SL, rules for data and operation refinement which allow one to
establish links between abstract requirements specifications and
detailed design specifications down to the level of code, and a proof
theory in which rigorous arguments can be conducted about the properties
of specified systems and the correctness of design decisions.The
previous descriptions were taken from the
Z FAQ and the
VDM FAQ
respectively. A comparison of both specification languages is
available in the paper,
Understanding the differences between VDM and Z
by I.J. Hayes et al.
-
Code Audits: Reviews of source code by developers other than the
author of the code are good ways to catch errors that may have been
overlooked by the original developer. Source code audits can vary from
informal reviews with little structure to formal code inspections or
walkthroughs. Informal reviews typically involve the developer sending
the reviewers source code or descriptions of the software for feedback
on any bugs or design issues. A walkthrough involves the detailed
examination of the source code of the software in question by one or more
reviewers. An inspection is a formal process where a detailed examination
of the source code is directed by reviewers who act in certain roles. A
code inspection is directed by a "moderator", the source code is read by a
"reader" and issues are documented by a "scribe".
-
Testing: The purpose of testing is to find failures. Unfortunately,
no known software testing method can discover all possible failures that
may occur in a faulty application and metrics to establish such details
have not been forthcoming. Thus a correlation between the quality of a
software application and the amount of testing it has endured is
practically non-existent.
There are various categories of tests including unit, component, system, integration, regression, black-box, and white-box tests. There is some overlap in the aforementioned mentioned testing categories.
Unit testing involves testing small pieces of functionality of the application such as methods, functions or subroutines. In unit testing it is usual for other components that the software unit interacts with to be replaced with stubs or dummy methods. Component tests are similar to unit tests with the exception that dummmy and stub methods are replaced with the actual working versions. Integration testing involves testing related components that communicate with each other while system tests involve testing the entire system after it has been built. System testing is necessary even if extensive unit or component testing has occured because it is possible for seperate subroutines to work individually but fail when invoked sequentialy due to side effects or some error in programmer logic. Regression testing involves the process of ensuring that modifications to a software module, component or system have not introduced errors into the software. A lack of sufficient regression testing is one of the reasons why certain software patches break components that worked prior to installation of the patch.
Black-box testing also called functional testing or specification testing test the behavior of the component or system without requiring knowledge of the internal structure of the software. Black-box testing is typically used to test that software meets its functional requirements. White-box testing also called structural or clear-box testing involves tests that utilize knowledge of the internal structure of the software. White-box testing is useful in ensuring that certain statements in the program are excercised and errors discovered. The existence of code coverage tools aid in discovering what percentages of a system are being excercised by the tests.
More information on testing can be found at the comp.software.testing FAQ .
-
Design Reviews: The architecture of a software application can be
reviewed in a formal process called a design review. In design reviews the
developers, domain experts and users examine that the design of the
system meets the requirements and that it contains no significant flaws
of omission or commission before implementation occurs.
-
Codified Best Practices: Some programming languages have libraries
or language features that are prone to abuse and are thus prohibited in
certain disciplined software projects. Functions like
strcpy,gets, andscanfin C are examples of library functions that are poorly designed and allow malicious individuals to use buffer overflows or format string attacks to exploit the security vulnerabilities exposed by using these functions. A number of platforms explicitly disallowgetsespecially since alternatives exist. Programming guidelines for such as those written by Peter Galvin in a Unix Insider article on designing secure software are used by development teams to reduce the likelihood of security vulnerabilities in software applications.
Issues Preventing Development of Secure Open Source Software
One of the assumptions that is typically made about Open Source software is that the availability of source code translates to "peer review" of the software application. However, the anecdotal experience of a number of Open Source developers including John Viega belies this assumption.
The term "peer review" implies an extensive review of the source code of an application by competent parties. Many Open Source projects do not get peer reviewed for a number of reasons including
- complexity of code in addition to a lack of documentation makes it
difficult for casual users to understand the code enough to give a
proper review
- developers making improvements to the application typically focus
only on the parts of the application that will affect the feature to be
added instead of the whole system.
- ignorance of developers to security concerns.
- complacency in the belief that since the source is available that
it is being reviewed by others.
Benefits of Open Source to Security-Conscious Users
Despite the fact that source licensing and source code availability are not indicators of the security of a software application, there is still a significant benefit of Open Source to some users concerned about security. Open Source allows experts to audit their software options before making a choice and also in some cases to make improvements without waiting for fixes from the vendor or source code maintainer.
One should note that there are constraints on the feasibility of users auditing the software based on the complexity and size of the code base. For instance, it is unlikely that a user who wants to make a choice of using Linux as a web server for a personal homepage will scrutinize the TCP/IP stack code.
References
- Frankl, Phylis et al. Choosing a Testing Method to Deliver
Reliability. Proceedings of the 19th International Conference on
Software Engineering, pp. 68--78, ACM Press, May 1997.
<
http://citeseer.nj.nec.com/frankl97choosing.html
>
- Hamlet, Dick. Software Quality, Software Process, and
Software Testing. 1994. <
http://citeseer.nj.nec.com/hamlet94software.html
>
-
Hayes, I.J., C.B. Jones and J.E. Nicholls. Understanding the
differences between VDM and Z. Technical Report UMCS-93-8-1,
University of Manchester, Computer Science Dept., 1993.
<
http://citeseer.nj.nec.com/hayes93understanding.ht ml >
-
Miller, Todd C. and Theo De Raadt. strlcpy and strlcat - consistent,
safe, string copy and concatenation. Proceedings of the 1999 USENIX
Annual Technical Conference, FREENIX Track, June 1999.
<
http://www.usenix.org/events/usenix99/full_papers/ millert/millert_html/
>
-
Viega, John. The Myth of Open Source Security. Earthweb.com.
<
http://www.earthweb.com/article/0,,10455_626641,00 .html >
- Gonzalez-Barona, Jesus M. et al. Counting Potatoes: The Size of
Debian 2.2. <
http://people.debian.org/~jgb/debian-counting/coun ting-potatoes/
>
-
Wheeler, David A. More Than A Gigabuck: Estimating GNU/Linux's Size.
<
http://www.counterpane.com/crypto-gram-0003.html
>
Acknowledgements
The following people helped in proofreading this article and/or offering suggestions about content: Jon Beckham, Graham Keith Coleman, Chris Bradfield, and David Dagon. © 2002 Dare Obasanjo
that just because you put your source behind lock and key doesn't mean it's any more secure. I hope more companies realize that competent programming and fast security patching is more effective than cloak and dagger secrecy.
That should be kept in mind when trying to draw conclusions from raw numbers of vulnerabilities.
I just realized they chose the shortest month of the calendar year to do this. Do you suppose they have a 31 day plan and things will fall short and it will be rushed, thus leaving holes? ;)
Slashdot invented the GNU Mailman? Cool!
It should be noted that you just cant apply a blanket statement and say "Code Audits by somebody else can help reduce security vulnerabilities". We need to have people looking at the code who understand the security problems, understand the code and understand the underlying protocols (if any). I might be able to do a great security specific code review on a "Hello World" app but point me at the Kernel and I am lost (I think a lot of us would fall in this category).
of opensource the fact that when a vulnerability is found, it is then patched / fixed / hacked / whatever / and then distributed.
.02 of rambling
I mean, lets be honest, how many of you programmed some code and it worked perfectly the first time? Maybe sometimes, but even the small programs we forget a " or a ; here and there....
This is putting the works of many, many people together to compile a "program" that is larger than anything I could even dream of accomplishing. i.e., there are bound to be flaws we didn't see in the multi-millons of lines of code.
Back to ontopic.... A security hole is found, we can patch it because we can see the code, we can make it BETTER.
Microsoft....
well, you just wait and hope they eventually make a patch, and half the time the patches suck and are re-exploited in a matter of days.
I'm not claiming that opensource is non-vulnerable or exploit-free.... So this article seems somewhat pointless. Anyone who writes code, knows that an exploit free program of this size is just dreaming. What should really be looked at is the amount of time taken to fix and patch a problem.
Just my
www.slightlycrewed.com - Because aren't we all?
The author wants to "expose the fallacy of the belief in the "inherent security" of Open Source software" (many eyes make safer code) and gives the REAL way to make software more secure of which these 3 caught my eye:
Code audits
Testing
Design reviews
Correct me if I'm wrong, but isn't that exactly the "many eyes make safer code" theory? That open source, having the code available, can have more people do code audits, testing and design reviews than a company with closed source can.
In the real world, he's right, those extra eyes aren't necessarily qualified...but still, on AVERAGE wouldn't there be MORE qualified eyes to do this stuff along with the unqualified?
"I'm not a procrastinator, I'm temporally challenged"
1. Formal Methods
Yeah, good luck getting Johnny Hack-job that has an associates degree in C programming to use formal methods. I can imagine the interview process now:
Interviewer: Are you familiar with formal methods?
H4X0R: Huh?
Interview: Are you comfortable with set theory and first order predicate logic?
H4X0R: I know how to code. I learned how to program in C. I am an 3l33t h4x0r.
Interviewer: *sigh*
It is true that you can have just as many security problems in Open Source, but those security problems are not hidden behind clever marketing. The code is out in the open and can be fixed by anyone who takes the time to do so.
Microsoft could even have a better track record than some Open Source systems and I think that I would still choose the open source way.
If you rely on obscurity to be your software security then you will lose every time. In the end it is the freedom to choose and to change in the open that makes a system secure.
Tony
No, Dare, you're wrong my friend.
In fact the belief in the inherent security of Open Source software over proprietary software seems to be the product of a single comparison, Apache versus Microsoft IIS.
No, I'd venture to say that although you are correct in citing IIS' tendency to destroy the Internet every few months when another virus comes out targeted at the Microsoft web server, there are most definitely other pieces of Microsoft proprietary crap that looks pretty lame when compared to its open source or free software counterpart.
Ever hear of Microsoft Outlook?
If you celebrate Xmas, befriend me (538
The author's point is correct - while any Open Source package may have been audited, it isn't neccesarily audited well or at all.
But flash-back to the recent announcement of the Sardonix Security Portal, which aims to be a central clearinghouse for tracking audits and auditors. The goal is to have a list of 1) what's been audited, 2) who audited it, and 3) what that particular auditor's track record is on other software - were holes found after they said it was clean?
Obviously this is a new project, and it's founded on the ashes of an earlier effort that didn't get much involvement, but it's a big step in the right direction and it's got DARPA funding. And it probably will do much better jobs with Open Source software than with Closed Source.
Everything Solaris recently posted a slew of articles, showing that the Solaris community is alive and well. Featuring Open Source software, articles like "Providing Core Customer Services" discuss how to set up that new infrastructure with both Open Source and high-availability in mind. Other interesting articles include, "Replacing Sendmail with Postfix" and "Upgrading to ProFTPD..."
Of course not.
But, better that it's more securable in theory (due to the open nature of the source) than not securable at all.
Mmmmmmm. Floor pie!
Splint is a GPL'd extended-lint type code analysis program which not only checks syntax (and semantics!) but now includes checks for security vulnerabilities. Essentially you run your code through Splint and it will spit out a detailed list of problems. As with LCLint you can "decorate" your code with stylized comments to provide semanatic information to the parser which allows even more thorough checking. Click here for more details and downloads of Splint.
The term "peer review" implies an extensive review of the source code of an application by competent parties. Many Open Source projects do not get peer reviewed for a number of reasons including
* complexity of code in addition to a lack of documentation makes it difficult for casual users to understand the code enough to give a proper review
"Casual Users" are not peers. The term "Peer Review" means that, in this case, the code would be reviewed by other hackers (software engineers), not by the general public.
I am not a hacker, I don't have the skills or knowledge to find security holes in software libre by reviewing the source code. All I can do is use the software, and if I come across a sympton of a problem, I can email the developer to ask what is going on, which often results in a patch within a short period of time.
I use vsftpd, (vs stands for "very secure" and is a goal, not a declaration of its status). Included with the source are a number of explanatory files you are familiar with: README, INSTALL, Changelog, LICENSE. There is another you probably haven't seen: AUDIT. AUDIT lists each source code file and a rating of 1-5 to indicate how much scrutiny it has received from other competent parties. 1 indicates no scrutiny and 5 means many competent programmers have reviewed it. Most of the files are rated 2 or 3.
I think this is an excellent idea, one that should be expanded upon by other developers.
Oh, and vsftpd 1.0.1 can be obtained from this ftp site at Oxford. It's written on Linux but I run it on Solaris with just a tweak to a #define.
Edith Keeler Must Die
It's dangerous to simply judge the security of an operating system simply on published vulnerabilities. First, discovering vulnerabilities is a non-trivial task; secondly, some operating systems recieve more frequent audits, resulting in a higher number of discovered vulnerabilities; and thirdly, some operating systems are more-transperant, resulting in a higher number of discovered vulnerabilities.
Take, for example, Solaris. Solaris is the most-used Unix in the world; it is under more external scrutiny than any other Unix, and so you can expect more discovered vulnerabilities than for HPUX or AIX. This doesn't mean AIX or HPUX are intrinsically more-secure; it just means more discovered vulnerabilities on Solaris.
(I don't claim AIX or HPUX is as insecure as Solaris; I'm just saying it's impossible to judge based on number of discovered vulnerabilities.
(And Solaris is pretty secure.)
Then, the BSD and Linux variants are more transperant; anyone can look at the source code, and so possible vulnerabilities are easier to identify.
Nice article, and excellent analysis. My quibbles don't undermine your conclusions; I just *hate* it when people simplify security to number of discovered vulnerabilities.
Security is much more complex than that.
Microsoft is to software what Budweiser is to beer.
It just doesn't jive. Some closed source software is more secure, some OSS is more secure. It depends on the talent, hardwork and organizational skills of those involved in the individual projects.
Even if one found a methodical way to compare the mean security level of OSS and closed source software, it would be of no use!
What use is it telling someone Closed source software is in general more secure than OSS when they're only interested in a web server? What they need to know is how secure their potential solutions are.
Also, knowing which method in general produces more secure code won't influence a development team. They have more important things to worry about, ie. how they intend to profit from their work.
Liberty.
I'm curious as to the relative market share of the various operating systems they listed. Wouldn't it be expected that more popular systems would have a greater percentage of their security holes found? If only ten people used some os, you'd expect very few vulnerabilities to be found...
Gene Spafford gave a very interestring talk on Why Open Source software only seems more secure at LinuxForum 2000.
It was a real eye opener for all of us who had read The Cathedral and the Bazaar
For instance this from one of the slides from the talk:
Linux compromises dominate - nearly 4 to 1 over Windows
Commercial Unix compromises usually rare
Windows/Unix compromises are 2 to 1
MacOS compromises do not occur (before OS X)
The slides are still interesting even after two years
I think what people are losing site of here is the options you are provided with in OpenSource. While on a Windows platform there are relitivly few companies that make server software(ie FTPd, http), while on the OpenSource Platforms there are many more choices.
:-)
How many people would run WuFTPD on a production box while there are other options around like Pure-FTPD or ProFTPD?
But for windows for example there are relitivly few closed source HTTP Servers. Namely IIS, while on the open source side there is everything from Apache to Abyss.
So what this brings me to, another point of Open Source Software, because there are many *options* in a production enviroment for the choice in software, the only costs of changing to a product that is more secure is the time to install it. While in closed source to get Microsofts newsest and most secure IIS 6+++ bundeld with Windows ZP 2003, you will have to shell out a few grand. Thats where security matters in the end, how much money does it cost you in a production enviroment. We are a bunch of capitalists at heart you know
Personally, I find remote vulnerabilites to be a MUCH greater concern than local ones. Looked at this way, we can see Linux clearly coming out ahead, which the champ Debain with only one vulnerability.
The author does make a good point about open source giving a false sense of security. Just because the source is available doesn't mean that it has been thoughouly audited. Still, the freedom to do so is there.
-- When a fool hears of the Tao, he will laugh out loud.
"One deterrent to the mass review of certain Open Source projects is a high level of complexity in the code, which can be compounded by a lack of documentation."
Please, closed source is no different. Just cause a company produces code for money does not mean they have tons of documents and all the code is easy to read. Bad argument just because a code base is opened or closed does not brand it overly complex or neat and clean automatically.
Yes but every time I try to see it your way, I get a headache.
This was a fairly reasonable (if unexceptional, being a rehash of a rehash) article, until the author got to his recommendations:
However, all of these issues can and are solved in projects with a disciplined software development process, clearly defined roles for the contributers and a semi-structured leadership hierarchy.
This is almost certainly not the path to better free software. Mass movements in the free software community develop bottom-up, not top-down. If the community rises to the challenge of creating secure software, it will happen for the same reason as any other of our successes: because individual contributors see it as worthwhile.
So if you want it to happen, don't focus on rules and leadership. Focus on ways to increase the visibility of good security work and to credit its practitioners. Make people care.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Wanna make security better? Come do something about it.
Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for purchase
It's funny that this story immediately follows the one where Bruce Schneier says it best:
"Publication does not ensure security, but it's an unavoidable step in the process."
There is quite a big difference between security problems in commercial operating systems such as Solaris and security problems in open source operating systems such as Debian.
The Debian team did not write most of the software that comes with the Debian distribution. Sure they make patches and try to keep things up-to-date, but the software that is in their distribution is included for completeness more than anything else.
Sun on the other hand did write most of the software that comes with Solaris (or at least obfuscated where it came from.) They are directly responsible for security problems with the software they distribute.
When a security problem occurs in Apache, surely it's an Apache security problem that just happens to affect everyone who has Apache installed. If they have Apache installed on Windows, one can't claim it as a Microsoft security bug and blame Microsoft for not auditing every peice of code that happens to compile for their OS.
No one forces the end-administrator to install 99% of the software included with an open source distribution. It is up to the administrator to only install software which they are comfortable with. If the authors of Emacs don't do frequent code audits, don't install it (that's not to say they don't.)
Now... one thing distributions can do to make the end-administrator's job a bit easier is to include statistics along with the application for things like past security vulnerabilities, time since last vulnerability, last code audit, etc. to help them make better decisions about what to install and not to install.
Of course, going the route of only including fully audited code in a distribution just doesn't work. If people need inn, they need inn code review or not. Granted they might take a look at the source while they are compiling it, but the chances of them finding a massive security hole with a curory glance is pretty slim.
That's not to say that distribution vendors are free from blame; especially fully commecial vendors who should at least do some form of audit and mark which packages haven't been audited as 'unsafe,' but come on now... the real blame belongs with the administrator and the developers.
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
Why is it that people say X holes here, or Y bugs there.
Bugs are given ratings on their priority, I assume security holes are as well.
I looked through some of those security listings and noticed that some are for applications that are bundled with the OS (so I'm not sure that they should be counted as an OS issue) and that don't result in actually compromising the system (perhaps crashing an application, or corrupting a file, yes). Not that I'm saying that is a 'good' thing but certainly crashing a little-used application which may not even be running on the default install isn't the same as gaining root access nor should they be treated as such; some form of 'validation' of the numbers is needed, e.g.:
Easily Exploited (278):
-- Root Access: 234
-- Crashes programs: 44
etc.
Thanks,
--
Matt
Does anyone find the use of formal methods any practical use ?
I studied them at uni, and found them dreadful things to use at the time. The main benefit to using them seemed to be that they took about 5 mins per line of source code - anything you do that makes you spend that amount of time looking at your code is going to help you find problems. But I might have been biased, because I wasn't an experienced programmer back then.
Does anyone have any different opinions on this ?
I dare you to put an AIX box external to the internet! Sheesh. M$ doesn't get it... this guy doesn't get it either. The best way to improve quality is with everyone testing things out in the open. If you try to hush up things, nothing gets fixed (as is the case with most of the commerical *ix platforms) and holes abound. The reason you don't hear too much about the other *ix platforms is because not as many people are interested in hacking them. A piece of software with no bugs is likely a BAD piece of software... not a good one. So report your problems.... report them all.... or be like M$ and many others who try to hide them as best they can and fix them when convenient.
Probing the defenses: looking for where the code doesn't anticipate a certain condition, isn't very efficient, but has been pretty much the way vulnerabilities are found.
Intelligence: lack of source availibility is depriving yourself of 1,000 eyes to find the vulnerability, thus it remains. If their closed code is stolen, without the benefit of freelance auditors, the problem compounds, exploits are found and can be executed when and where they can do the most damage. Open source is inviting those, 1,000 eyes of freelance auditors to report a vulnerability. There still remains the chance some unethical person will spot it and not report it, choosing to exploit it later, but they play roulette in that someone still may find the hole and close it.
A feeling of having made the same mistake before: Deja Foobar
OK, these technical issues are beyond me, but my perception of this is... in a big picture way...
Private companies claim security features in their software. They tell their customers that with this, security is assured.
Has any free Open Source softeware EVER claimed this?
As far as I know, every Sys Admin I've ever talked to tells me that nothing is secure on the Internet... it's simply not designed to be! Never was! Hence, claiming Open Source software isn't secure is false - as nothing is secure. What I mean is, claiming security is a lie, you're only as secure as the Admin can make it.
Open Source was and should never be billed as a "magic bullet" that will fix anything. This includes security.
However there is an important feature of Open Source projects over proprietary stuff is that "openness" breeds honesty and trust.
If a bunch of people say Apache is secure(pulling an OSP out of the air) it is not only because people use Apache and found the claims to be reasonable but people have looked at its open internals and believe that its design is secure. If a bunch of people say IIS is secure(pulling a related closed product out of the air) there seems to be less credibility. Although people do use IIS no one really knows much about the internals of IIS except Microsoft.
Especially with MS's recent performance, are you going to trust the vendor's claims that their closed product is safe and secure? At least with the source you can hire people to do security audits on Open Source programs.
Keep in mind that Microsoft and Apache Project both have the same "no warrenty" on their programs. If you use them and something goes bad(ie. you get hacked) it isn't our fault. It turns out that Microsoft's scheme isn't better and it costs more(you have to buy the product, you have to buy support from Microsoft, you have to pay for them to look at your problems). So why do people continue to believe MS over Apache?
And lastly, Open Source doesn't fix user stupidity. Apache for instance can be very easy to break if you configure it very poorly and IIS can be very secure if you take the time to tighten it.
so what? at least i don't round up farmers into a gulag and kill them
Ok Microsoft's bug policy is a little shifty, but... linux still isn't bugfree either. Basically we're talking millions of lines of code so the number of bugs is going to be in the thousands. Now with open source the thought is that anyone can review the source and find and fix bugs. Now in actuallity I would say that the number of people that actually have the ability to understand the code is much much much smaller than the number that use the software. How many people here have written software? And how many times does your a bug show up over the littest mistake, that took you 3 hours to track down? Its for this reason that bugs will always be around. Microsoft might not have the manpower due to be a private company to track down and fix all but open source (linux, bsd,etc) don't have the raw numbers of abled programmers to track down the bug. At least open source is alittle bit more, well open about it.
can't sleep slashdot will eat me
The data for Debian GNU/Linux is completely flawed. The OpenSSH CRC attack compensator bug is not listed, for example, and many remote vulnerabilities for which DSAs where issued aren't counted, either. (And the bugs other distributors fixed in 2001, and not in 2002 like Debian.)
In any case, if you are a Free Software zealot, you should seek for better arguments than security. Otherwise your friends will come back to you and ask, Why have you betrayed me?, when their machine gets hacked although they use Free Software which has been reviewed by thousands of capable programms.
Software shouldn't be viewed any different that any other tool - cars, VCR's, Microwaves etc.
Sure, there are some additional problems, but most come from the design and implimentation _approach_.
If you've read "The Software Conspiracy" from Mark Minasi, you'll be enlightened about software design, and our expectations.
Closed vs. Open isn't the point. Either can be just horrible, or quite wonderful. But the devil is in the details.
What I think many miss is that BUGS = INSECURITY! Not all bugs will cause an insecure system, but some will.
To make a more secure system, we need to make a bug-free system, or nearly so. Look at these software design and implimentation methods.
Formal Methods
Code Audits
Testing
Design Reviews
Codified Best Practices
These are the very practicies that will give good code, even bug-free code if they are followed carefully.
Now, as part of the whole solution, you need more than a solution. You need a "push" too. Pull isn't enough by itself.
It's my opinion that there are a couple of factors that could make this happen.
User demand. We havn't seen much of this, but it may be growing. We also need to work to change the expectation of users. Most of us even, feel that "Oh, it just crashes sometimes" is an acceptble answer. In fact, how many of us, just add the "just reboot, it'll fix it" to the mix. I'm as guilty as anyone. But this just perpetuates the expectation that software isn't very reliable, and we shouldn't expect it to be. Lets change that.
Finally I think the legal route should be available too. [I'll get lots of flames here, but I'm ready...] Like any other DEFECTIVE product, the user should be able to redress damage from a product that wasn't reasonably designed. [Many of you will be howling to burn me at the stake now, but read on if you can] The standard for liability is a reasonable effort. I think those that don't use a strict design and implimentation method are not using due care. These methods have been around for some time now. We just don't use them. It's also fairly clear that they can work. How well they can be implimented in real commercial products we can't know, becuase I don't know of anyone that really uses this type of design method - do you? [And not just in name. In real methodical plodding fashion...]
Lastly, as in Minasi's book, many of you are now screaming - "It'll cost WAY TOO MUCH!"
Bah! How much of your time is spent chasing bugs down in commercial products. Sure, it only cost $100 at the store, but you put in 35 hours figuring out how to work around bug a,c & c. It crashed, and lost your document. It took 3 hours of tech time to find and restore the right version of the data file, or worse, it wasn't backed up, and poof! Companies spend way too much on support of bad products. These costs never get allocated to the real source, but instead it's just lumped into the general support costs. That just allows the vendor to shift the cost to your company, rather than having an "honest" cost of the product up front.
If software vendors had the real threat of laibility, they would then get serious about coding practices. If they didn't, the corp boards and shareholders would make sure it happened. A few examples, and we'd have better software.
Finally, I think that legal liability is the only way this will happen. Until everyone is forced to a higher standard, everyone will seek the lowest common denominator. If you produce better software, but you're new, how will you charge more for it? I just don't think the "market" will fix this. [Not that the courts aren't part of the market, but many will argue they're not, incorrectly IMHO.]
In the end, frankly, OSS might be easier to fix, but who cares? I think the design and implimentation before and while the code is written is much more important. From that perspective, I think OSS has a more difficult time imposing that regimented framework on it's coders and design people. But it's lots easier to show and embarrass the OSS people, precisely because the code is open - thus a better motivator perhaps?
Well, I've said my piece - do your damage.
Microsoft typically will give you the kitchen sink, everything runs even if you need very little. RedHat linux does a similar thing, if you install "Everything" it also starts all the daemons.
If you don't spend 30-45 minutes turning off unwanted services, portscanning your machine, and looking up patches/updates at CERT/RedHat/SANS etc, forget it.. your system will probably get compromised in a matter of days. This goes for *ANY* operating system, you simply have to test it and make sure you are running the minimum necessary to do the job.
The main reason you hear more news about microsoft systems getting infected is simply that there are many more of them, and many more are running the simple default configurations. Linux machines are really just as vulnerable IF YOU DON'T PATCH AND TEST THEM
Here's a little guide to turning off unwanted services on a redhat box, and how to audit your systems with a portscanner
The idea behind Open Source is that any old person can pick up the code and start coding. The problem with that is that the average coder isn't qualified to do security coding. Please note that this is NOT TO SAY that the average 'closed source' programmer is any more or less qualified; I dare say most of them aren't. But the 'more eyes' arguement can only apply if those eyes know what they're looking for, and I dare say also that the relatively low barriers to entry in the OSS world would make for more 'elementary' coding mistakes, and for software that 'starts wrong' with poor infrastructures, simply because they're often learning processes for the creator.
Vintage computer games and RPG books available. Email me if you're interested.
You sir, are not familiar with slashcode.
Story submissions do not pass through the lameness filter, or the tag filter. So get your malicious javascript and disgusting <img> tags ready. Annoy those peon slashdot story submission queue monkeys.
In theory, open source has a greater POTENTIAL to be secure than non-open products. I say potential because while it may not happen in practice, there's a lot more opportunity for numerous people to look at it with diverse perspectives. Of course if they don't look at it, it doesn't much matter.
the other security benefit of open source is that you have the POTENTIAL to audit code before you install it. If security was absolutely critical to you, you could look at the innards of every app you download, skim it for buffer overflows, etc. In practice most people don't bother, but they could if they wanted too.
This sig has been temporarily disconnected or is no longer in service
2. I see Red Hat has an "unknown" vulnerablity. WTF is that? Is it "I think there might be a vulnerability here but I don't know"?
i don't dig farmers, what a silly silly lady you are, mrs. stalin
Sendmail source has been available for decades, and security holes have been reported steadily for its entire life. What went wrong?
What I would really like to have now is the taste of sweet, virgin cornpone country pussy...
The owls are not what they seem
is wrong because it lists the glob problem twice, once for ftp and once for libc.
Open source security may be a myth or a theory,
but the fact remains. For better or worse, at least I am 100% capable of finding the bugs or security holes if they need to be assured of such.
You can say all you like about how little guarantee there is with the code being open, but with the code closed, I can only find problems, I can't assure myself there aren't any more.
-Restil
Play with my webcams and lights here
Maybe I didn't make myself clear, what I intended so say was that the idea of 'sweeping statements' like the one the article debunks are a load of crap, not the article itself.
It looks pretty silly when you insult the article and then make a post where all your points are pretty much the same as in the article (ie. OSS and closed source software can both be secure or insecure).
As I said, it wasn't my intention to insult the article but the idea which it calls a myth ( and it's opposite). In fact, I was insulting the notion of one side being more secure, as well as the notion that finding such an answer is useful. That's what I called a load of crap, the whole debate in the first place :)
Liberty.
thank you, for my next trick i shall invent sibling rivalry
... is the relative speed at which open-source problems are located and repaired.
Just for fun, here is a handy summary of some Windows issues, including an XMLHTTP vulnerability that allows a malicious website to read any file on your harddrive, that has been a known issue since December 15th.
That site started out lame and went rapidly downhill from there.
The only known and proven way you can get problems like buffer overflows under control is to use high-level languages and tools that make them impossible. Yes, your programs run slower, but a compromise is much more expensive than a couple more machines. Yes, there will still be plenty of other security holes possible, but we can address those through better tools as well.
Microsoft's management approaches to security are doomed to failure, as are efforts and arguments in the open source community that the open source process magically addresses security problems. Microsoft's real security initiative is their switch to C# and "managed APIs". The open source community should take notice. Unless systems like web servers, file servers, mail servers, and authentication under Linux get rewritten in safe, high-level languages like Java, C#, or others, Linux will be so unreliable relative to Microsoft's and other systems that it will become irrelevant.
(However, given the choice between buggy Microsoft C++ code and buggy open source C++ code, I'll still take the buggy open source C++ code any day--it's easier to fix and fixes come out more rapidly.)
Interesting to note that people somehow equate "more vulnerabilities found" with "less secure". The fact that these vulnerabilities are found, made public, and fixed shows that Linux has a better review system than Windows, not less security. What would happen, I wonder, if the Windows source were made public? Would the list include hundreds or even thousands of potential hacks?
Max
My god carries a hammer. Your god died nailed to a tree. Any questions?
I for one will never, ever again trust a fundamental part of infrastructure to anything closed source. This goes for stability, security, bug fixes and product lifetime.
Simply put, open source has become for serious developers a prerequisite. It means that while, yes there will be flaws, that you cannot be held hostage by these flaws be they security or functionality by the vendor. No amount of arguing statistics can change this. Developers have seen the light and will not go back, sorry.
So articles like these are really just moot. I really don't care if AIX had fewer security flaws than Linux. It only takes one. It only takes one bug that interrupts your business, and one IBM policy change, saying, 'sorry wait for the next version', or 'sorry, we don't support AIX anymore' for you to be over the barrel. This is serious business and there is a lot of money and time involved. If a vendor drops your product, or even slows down it's bug fixes you _will_ be in trouble.
"We're not suggesting that Microsoft must give up all proprietary rights to its protocols and interfaces, or allow anyone to implement or use its standards. We are saying that they must be public, not secret."
Why is that? I would finally love to be able to mount (read&write) a NTFS partition should the need arise. Now they don't have to give up properiatary rights to their protocols or interfaces; thats fine. They can have (c) Microsoft etc; however people SHOULD be able to implement and use it's standards for interoperability, so I disagree with that statement. The protocols/interfaces/records/structures should be public and people should be able to interoperate with a Windows machine without having to reverse engineer protocols and structures.
Absolute, 100% agreement. Microsoft gets much higher security for free by using C#.
rather than picking apart minor quibbles in the article, and thus trying to disclaim it entirely, we should look at the big picture and learn from it.
just my 2 cents.
People make the mistake of thinking A=B thus B=A. when it comes to peer review and security. It's not that type of relationship though
Peer review doesn't guarrantee security.. but lack of peer review guarrantee's a lack of security.
Open source has the potential to be secure because it has peer review. (Again, there's no guarrantee that anyone will look at the code, or if they do, find any or all security flaws that exist in the code).
Closed source cannot possiblity be secure because it lacks peer review.
That's how it boils down.
Open source _could_ be secure.
Closed source _can't_ be secure.
The greatest property of Freely available sources that affects security is the fact that a larger community can improve the sources. To leave security at the hands of a private few will always result in changes that reflect the needs of the few (cost, marketability, etc.).
... or if nothing else, individuals will have the freedom to improve the security themselves.
Again the numbers presented in this security comparison are incomplete - and poorly weighed. The number of security holes by distribution must be considered along side number of installations, nature of the installation, severity of hole, time to repair, time to notification, cost of comprimise, etc. For example, how long does it take for a Gnu/Linux or BSD distro to post a patch to a security concern? How long for HP, IBM, or Microsoft? How many Unix based security flaws cause wide-spread problems? At what cost (comparison)?
I think Freely available sources have a better chance at improving rapidly outside of the concerns of a Big Evil Empire - the motivations are warped by lesser concerns (namely not by greed). The Big Evil Empires are not primarly motivated by the desire to improve their sources (generally), but rather by business and other greed-centric concerns.
I have greater trust in security when I have the Freedom to have some impact on its quality. Why would I trust a greed-based development system to ensure my rights are first? A community based system - at least in the long run - will be more secure
mx
It's usually tight code because the programmer is doing this for the love of the art itself, and for the notoriety of publishing their code in public.
Contrast this to how a lot of corporately driven software is designed: Committee decisions, Edicts from ignorant higher-ups, and programmers who have no stake in doing a good job because almost nobody appreciates good clean code or even knows enough to recognize a crufty block of garbage.
I'm not suggesting that ALL corporately written software is done this way, nor am I suggesting that ALL Open Source software is good either. But the typical motives behind the origin of the software and thus the design itself are quite different.
One of them encourages good code and the other one doesn't. Is there any wonder why it's so expensive for Microsoft to find and fix a bug, while open software tends to be pretty usable even on beta releases?
Nearly fifty percent of all graduates come from the bottom half of the class!
These two libraries are the biggest causes of buffer overflows in C. Use a language or library with dynamically strings and the problem goes away. Unless you are writing a system utility or speed critical application, interpreted languages are a reasonable choice - you can always throw more hardware at a problem.
Life is a psychology experiment gone awry.
Let's cut back to the big picture. Pick any desirable characteristic of software -- resource efficiency, robustness, quality, and, yes, even security -- and guess what? The process by which the software was created largely determines how much of that characteristic the software exhibits. Good work, good code. Crappy work, crappy code. Not exactly a news flash.
Now -- and here's the important part -- take any software, developed by any process, and then consider any desirable characteristic. Do you get more of that characteristic by letting everybody see the source or by keeping it hidden away?
That's the argument for open source.
[As I responded to the author's original posting on Kuro5hin.]
Easy, automatic testing for Perl.
"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."
"The open source movement hasn't made the problem of buffer overflows go away. But eventually, newer programming languages may; unlike C, modern programming languages like Java or Python never have buffer overflow problems, because they do automatic bounds checking on array accesses. As with any technology, fixing the root of the problem is far more effective than any ad hoc solution."
I call on all Open Source programmers to switch to one of the new languages which cannot have buffer overflows.
The beauty of the Open Source/Free Source community is that they choose solutions because they are the BEST solutions. Not because of some commercial concideration. You don't want to become as good as Microsoft. You want to become better!
The new languages are the way of the future for software. I believe you'd rather be programming for modern times than be stuck in the past.
I have read that the open source community has some large egos but I want a mass migration from the old languages to the new. Even if that means that you have to abandon your old favorite language like C++. I know it hurts.
Let this beautiful philosophy of "Always choose the best solution" please survive into the future. Otherwise buffer overflows will always exsist.
Oh and .NET can still have buffer overflows and other security holes. That means it's an intermediary solution at most, it doesn't hold the future. At least it shouldn't.
The time between a bug being discovered and being fixed. That is a kicker. Let's suppose that you had two pieces of software. One had twenty security holes found in a year, but every hole was fixed in one day. The other one had five holes, but they took six months to be fixed. Which piece of software had more known security holes at any given time?
The big issue is 'how many unresolved security holes are there for software X at any given time'. Even more than the number of bugs, that is a really significant number. Microsoft execs are whining about people discussing bugs out in public. The fact is that people started doing this in order to get companies to correct their code.
I won't say that OSS is more secure than proprietary software. I will say that OSS on average tends to have a much higher turnaround for getting bugs fixed and not leaving a system with known problems for very long.
Well, one can certainly rewrite wu-ftpd or bind in java, and it will not have buffer overflows. Unfortunately one will also have to upgrade theyr PIII servers to 256-CPU IBM mainframe to get equal performance.
Everybody Lies. But it doesn't matter since nobody listens.
No, it's just that most peole can't be bothered wasting time over shit.
Microsoft - Where would you like to go today, Maybe Jail?
Nothing wrong with vulnerabilities being found. If they aren't found, that occasional "crash" is dismissed as an annoyance. Vulnerabilities are bugs that are picked apart for all they are worth including the means to pry open a back door.
Finding these weaknesses, or "sploits" are a win in the long term for people who enjoy a reliable, bulletproof system. It has to be hacked and torn apart to the point of perfection before one can be proud of reliability.
Just because a piece of code is open source does not mean that it has been audited by competent security auditors. Of course the same is true of proprietary software. I think that open source software can be more secure, however, for the following reasons (though these could apply to proprietary software as well).
1: Access to source: Just because it has not been audited does not mean that it cannot be audited. Software can be considered more secure if the code is at least available to be audited. For this reason, I congradulate Microsoft on the shared source initiative.
2: Independent audit: When in doubt for a mission-critical scenario, hire someone ot audit the code or part of it. This is possible with porprietary software under some licenses and with permission from the vendor, but it is always true of open source.
3: Compartmentalized design-- application runs under minimal permissions. This is a problem with proprietary (IIS) and OS (Sendmail) software alike.
Open Source is no guarantee for security but it helps.
LedgerSMB: Open source Accounting/ERP
I really thought OpenBSD had a better track record than this. Guess I'm blinded by their website :)
I admit that this comment is going to sound very ad hominum: We need to examine Obasanjo's claims carefully. He's worked for Microsoft very recently.
Ordinarily, I wouldn't call attention to this, but Microsoft as a company has a really bad track record of astroturfing just about any kind of on- or off-line forum:
Sorry, Dare, but that's the facts: if you lie down with pigs, you wake up smelling a bit like pig excrement.
Of course Linus is buggy and insecure, he's a human being. Linux and Windows and *BSD and other Kernels/OSs are buggy an insecure 'cause made by human beings.
The question is, how the human beings are handling their errors.
To compare the number of errors of bare Windows and a complete GNU or BSD system is a stupid thing, IMHO. "MS Windows" is to compared with "base installation" plus "x11" or so, for "MS Office" some packages of KDE OR(!) GNOME would be a fair thing. In the case of Debian that's less than 10% or so of the whole distribution.
As I'm subsribed to debian-security-announce@lists.debian.org I get mail like "[SECURITY] [DSA 109-1] New Faq-O-Matic packages fix cross-site scripting vulnerability" every week.
I never heard that MS offers such a service. 4/5 of those mail is not interesting for me, as I'm not using all packages. In the case of Windows, 95% of the people have the same stuff installed, I bet. The difference is made by different versions. In the cases where the security alert is relevant for me, "apt-get install packagename" and a few seconds later the problem is solved (in the very most cases).
Yeah, yeah, yeah, that's what he says because his Mailman program from Red Hat 6. had holes. What a rotten extrapolation! Let's not FUD ourselves into a stupid panic.
The point of free software is to develop a community of users and gain mutual benifit by sharing code and development effort. Mailman? Pardon my ignorance of a bell on the "proffesional" Red Hat distro I never owned. How widely deployed was this package? If it was never that widely used, of course the bugs would remain. Thousands of downloads does not translate into thousands of users really and we might assume that a large portion of those users have upgraded their machines. It is much more correct to extrapolate free software security from Apache, sendmail, exim, openssh, xfree86, the list is very long indeed, where there is a real comunity of users. If a bell or whistle is broke, it can be replaced.
Red Hat, by coming closer to the bad old days of software distribution has left their user base open to some of the bad old day problems. Difficulty in getting updates makes problems. Who would put 6.2 on a machine? No one expects a CD to heal itself yet I'm tempted. I've heard good things about up2date but it's not as easy or dependable as apt-get update and upgrade by a long shot. That cozey old 6.2 environment... nah. Shifting focus from service and equipment sales to software vending is a bad bad idea. Should we let some small problems Red Hat has had run us back into the arms of MicroShit and the like? Nope.
The good news is that low usage also translates into low venerabilty for the rest of us. It's not like Mailman is "the standard" forced on everyone, and I doubt any of it's bugs are as bad as say Outlook's. Think about it. Did we suffer Code-RedMan a few months ago? No we did not. Nor did we suffer network instability over BIND problems and or any other Linux/BSD holes.
The free distribution methods are showing themselves to be best. While I know it's possible for my poor little Debian boxes to be cracked, I also know that the chances are far less than any windoze compooter. The most common applications ARE well reviewed, the rest are so variable as to make life hard for the would be Linux cracker. What potential is ever fully realized in nature?
DMCA, Hollings, Palladium. What might have sounded like paranoia is now common sense.
1) Hypocrisy. Everyone screeches as loudly as possible because the big, closed source vendors like Sun and Microsoft want you to report security problems privately. Well, okay, let's look at Apache. Now, let's look at their policy regarding reporting security issues.
"We strongly encourage folks to report such problems to our private security mailing list first, before disclosing them in a public forum."
Sounds like the same thing as Sun or MS. Why aren't we bashing Apache?
2) The recent SNMP vulnerability. Wow, many eyes have gone over the SNMP code. Check out the CERT list of vendors on this puppy. Those many eyes should have been going over RedHat, over FreeBSD (okay, in their ports), over Netscape's products (too bad they don't tell you which ones). No word on the CERT site about SuSE, Mandrake, et al.
How much you want to bet that it's one old hunk of code to do SNMP that has been ported from one platform to another over many years? Even if it isn't ... wow, don't millions of eyes look at Linux? Some might look ... few look very hard.
And I now proceed to duck and cover for the nuclear blast.
Every tim eI read one of these, I am always astounded how they can't use simple logic in thier arguments. They argue that X operating system had found more bugs than Y operating system. The assumption, the illogical assumption, they make is that X operating system must have more bugs in it than Y.
Since, logically, there is no way to determine which one has more total bugs (found plus unfound), the only recourse is to assume that both systems have roughly equivilent numbers of bugs.
From that foundation, whichever system can demonstrate more FIXED bugs is going to be the one that is more stable. All of the bugs listed by the article are not outstanding bugs, they are fixed.
"Your superior intellect is no match for our puny weapons!"
You assume that exploits are found by combing the source code. The majority of discovered exploits are found by actually exploiting/being exploited by them!
Blar.
This doesn't mean that "many eyes" doesn't help, it just means it is not a panacea. As as side note, based on results, I find it difficult to beleive that Microsoft does ANY peer review of code! Any M$ developers care to correct me on this?
The only known and proven way you can get problems like buffer overflows under control is to use high-level languages and tools that make them
impossible.
wow, what a bunch of ignorant FUD
C is an excellent language for systems
programming, and its quite possible to program in it quite securely... very securely even, after a year or 2 of good experience.
for OS's and webservers and the like you *should* be a somewhat experienced programmer, and you *should* have security in the back of your head when writing / reviewing code. AND, people who make nontrivial open source software tend to just as experienced as people who make professionally written software.
thus it's pretty ignorant to blame the language. Insecure coding practices are usually the result of a scramble to meet some deadline.
-pete
So using your metric the system where more bugs were discovered is more secure? That is the most ridiculous metric I have ever heard.
Bruce Schneier talks about measuring trustworthiness but then goes into a list about featuritis. While I don't think that enabling/disabling features by default is the answer (someone could just script the annoying click-thru enables anyway), that's not what I want to see. There is a way to measure trustworthiness, and its how I'd like to see Microsoft measured.
.DOC file format.
1. Honesty
When a vulnerability is discovered, Microsoft should freely admit it, admit it was their mistake, and not try to pass the blame or put a spin on it.
2. Accountability
Microsoft should be willing to accept responsibility for their products and any problems they cause. No more click through absolutions. No more blaming it on harware or third party applications or user error. If something I bought needs a fix, they should make it freely available, to the point of sending me a disk in the mail. If I shelled out $200 for their cardboard box, they can spend an extra buck to send me a disk and a stamp. If they feel a need to charge $201.50 in order to achieve accountability, so be it.
3. Responsiveness
No more brushing things under the table, hoping noone will post an exploit to bug traq. No more suppressing information for months until they feel like dealing with it. Microsoft is getting better about posting fixes online, but they have a long way to go.
5. Openness
Microsot should tell us what each product and each fix is doing -- *exactly*. They should describe the problem instead of villianizing those who find it. They should allow people to fix their own problems. I'm not mandating the open sourcing of Windows, but if they were serious, they'd think about it. Even if you need to sign a 100 NDAs to get it. A much more reasonable and realistic request is the opening of the
6. Cooperation
Microsoft should be more willing to work with other Software companies. No more DOS or Browser or Mulitimedia player wars. No more games with SMB or Java or HTML. No more buying out or undercutting the competition. Microsoft should accept that they aren't the only software developers in the world and encourage a more heterogeneous environment. Not only is it good for security, its good for business.
Furthermore, source code and plain text emails are the only way many OSS projects communicate. This means that if any work is going to get done, the code needs to be much more legible than if coder A can just run over to coder B's cubicle if he can't understand the code. This also promotes a high degree of modularization, due to decreased communication bandwidth/increased latency between developers.
The large number of non-code-submitting members of OSS project mailing lists is also a huge plus. Many people to explain things to that haven't worked with the code since the beginning of time means that the coders need to teach others about the code. Teaching is one of the best ways of learning!
Peopple say that Microsoft must have really good coding practices to be so sucessfull. This isn't necessarily the case. I have a friend that interned for Microsoft and he was telling me about the infomal tutorial he got on Windows internals. The reason power management improved vastly between Win95 and WinME but remained basically unchanged between NT4 and Win2K was that the main guy who wrote the NT4 power managaeent code left and so they could make little tweaks, but they couldn't read the code well enough in a larger sense to make any drastic changes and predict the results.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.
The conslusion is that the way OSS is developed means that code on average ends up being more easily audited. So maybe the many eyes aren't doing the auditing, but the many eyes (and mailing list readers/question askers) are making the code easier to audit for those who do audit the code. More effective audits mean better code.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.
He has encountered a different set of "users of Open Source Software" than I have. Most that I have met will tell you either:
"Security is a process, not a product."
Or,
"Open source is more SECURABLE than closed source."
Perhaps this is a myth that has already been debunked.
Sure, given large amounts of time and testing resources, you can make C programs reliable. But deadlines are a fact of life. That's why we need systems that allow programmers to write reliable code under real-world conditions and real-world deadlines.
thus it's pretty ignorant to blame the language.
I rather think it's ignorant to claim that C/C++ can be used for writing reliable and secure software under real-world deadlines when 30 years of experience show otherwise. Just look at the bug lists. It isn't working.
You see, after 20 years of programming (much of it in C and later C++), I have learned not to trust myself to do things right.
Sorry, I must be a simple soul missing something, but I never thought there was a lot of point to this `formal methods' stuff. A) Didn't Turing (and maybe Goedel even) cut a lot of the guts out of such things? How can you say a thing works right if you can't even prove that it completes? B) How can one be sure the formal specification which one is verifying as correctly implemented, is not merely an alternate codification of the same damn bugs?
:p ) far into formal methods because of these prejudices, and so i know next to naught of which i natter. nevertheless ... there is is.
I confess, i have not personally delved (dolved? dulved?
Every week I read a list of new vulnerabilities in a variety of platforms and widely-deployed network-exposed applications as they've discovered every week, compiled from a variety of sources.
I typically count a 4:1 ratio of Windows to Linux bugs, and 2:1 ratio of Unix to Linux bugs, with about 60% of the total bugs running on Windows and the other 40% on various embedded devices, Unix and Linux combined. Every now and then there's a MacOS bug, just to prove that real people are still coding errors for that platform. Of course, for a bug to appear on this list, it has to be a security bug.
Sometimes Linux has a bad week (e.g. sometime in Fall 2001 Red Hat released more advisories in a few weeks than they had released in the previous two years) and the number of Windows bugs outnumbers the number of Linux bugs by a mere 2:1. Other times the script kiddies congregate in Redmond and Windows vulnerabilities outnumber Linux 6:1.
I've _never_ seen Linux bugs outnumbering Windows bugs since Y2K. Sometimes Unix wins over Linux, but not often (certainly not if anyone's cracking Sun boxes that week).
And Pine/Kmail Vs Outlook, and Netscape/Mozilla Vs IE (ANYTHING Vs IE). Basically everything that connects to the Internet that has an analogue between open and closed source has been less badly cracked on the open side.
There have been some belters on the open side, of course and I've had a worm that got in through Bind myself. But, there is no way that I would ever trust closed source software to connect to the 'Net again.
I suppose that my experience is just "anecdotal evidence" but my experience matters more to me than any number of useless metrics, and the metrics given are useless; how sever were the bugs and how long did a fix take to appear? How many of the fixes appeared before an exploit was seen in the wild? The method used punishes the systems which fix bugs before an exploit appears and rewards those that sit and hope that the bug is never "hit" and so don't spoil their "security score" by issuing a vunerability report.
As for the suggested methods of producing secure software, big deal! Apart from formal methods these are all in widespread use by people interested in security. Formal methods, for that matter, do not (and can not) guarantee correct software; I have met two desigers involved in the Airbus 320 project and one of them refuses to fly in the thing and no one can forget the pictures of that Airbus doing loops over Italy with a full load of passengers.
The problem with the "solutions" is not that no one knows what to do but that many (eg MS) don't bother trying. Given a package which has not been properly reviewed before release it's pretty obvious that the open source version is better insofar that it gives the user a chance of doing it for themselves. In an ideal world the source does not matter; in the real world it does.
I don't think we need ex-MS employees coming round here preaching about security, frankly. Closed source removes power from the user and leaves them helpless in the face of bugs that require even a one character patch to the code. Open source gives the user a chance which s/he may or may not be able or willing to take to fix bugs quickly, or to find them first before the black hats, but at least it gives them the chance. Only an idiot would claim that that does not lead to higher security.
The only valid point in this article is that programmers sould write better code and check it more before release. Well, DUH!
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Main Entry: inherent
Function: adjective
: involved in the constitution or essential character of something : belonging by nature or habit : INTRINSIC
Makes sense to me.
Formal verification, on the other hand, is a joke. It requires an incredible amount of work for even quite trivial specifications.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
So registering with this site allows a record of your auditing ability. I wonder how this project would compare someone who autited a simple program like test.c versus say Mozilla running on QNX.
-castlan