Slashdot Mirror
Security of Open vs. Closed Source Software
morhoj writes "Cambridge University researcher Ross Anderson just released a paper concluding that open source and closed source software are equally secure. Can't find a copy of the paper online yet, but I thought this would make for an interesting morning conversation. You may not agree with him, but anyone who's on the BugTraq List can tell you that open source software isn't as bug free as we would all like to think." I found Anderson's paper, so read it for yourself. There are some other interesting papers being presented at the conference as well.
The Manufacturer's Estimated Time Before Failure is for physical goods - things that naturally wear out. Not software, which is at the very least a loose mathematical desctiption of a repeatable process. Software and security don't "wear out". If they seem to, they were broken in the first place.
I hope that was just CNet editorialization, and isn't indicative of the rest of this paper.
But i think security of software is often down to the admin... I mean you can secure any operating system if you know what you are doing and its easy to build an insecure box - linux and windows.
How secure is an out of the box mandrake install ? or a windows 2000 ?
A good admin who is a pro will work hard to secure his servers and patch and look after them - a bad admin is a bad admin regardless of the OS
I refuse to argue with Anonymous Cowards - if you want a discussion get an account....
Security bugs in software are inevitable : it is bound to happen , sooner or later. A properly setup system can mitigate some of these problems (ie. chroot, modified security kernels). What my concern is is how long and how public security disclosures are, and how long the affected vendor takes to issue a bugfix.
Be kind. There are too many mean people out there already.
Of course there are just as many bugs in open source software as in closed source. Most of it is even written by the same people: what they do at work is closed, what they hack upon during the night is open.
The main difference lies in the speed and motivation to fix the bugs. Open source bugs can be fixed by anyone, but closed source bugs need to be fixed by vendors who are afraid to even admit they exist, for fear of losing customers.
superblog.org: all your favourite blogs on o
There will always be software bugs as long as programmers are not perfect. The huge diffrence is the in a closed source environment you'll have to wait for patches from the vendor, or not at all. In the OSS you can patch it yourself, get the unoffical patches for your vendor, get diffrent up-to-date packages, or install the latest version from source.
OK, Open Source has a lot of bugs, but who does list closed source bugs? I'm sure most of their bugs don't go public, because it is not a good market technique... It isn't fair to compare both lists.
Just my two cents.
Anderson's point was not that less is better is that its irrelevent in the long run to compare open and closed source.
I mostly agree with him however I like open source software for more reasons than just the fact its "more secure". Often OSS software isn't in fact more secure or reliable. Look at mozilla. Its a great project but its not as nice as IE by a long shot. Anyone using 1.1a in Linux will know that [e.g. me! while at the same time 0.9.9 works fine... ???]
tom
Someday, I'll have a real sig.
Security != number of bugs. There's 'severity of bugs' and 'speed of fixes', not to mention the OS's and software's design in the first place--think permissions, user spave vs. kernel space, etc.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
This is certainly true, however there is a large amount of security appears to come from the community / vendor around the code too. Yes, I'm generalising, but open source programmers treat security problems as security issues, rather than as a PR problem. Even though the apache team ( rightly, in my opinion ) criticized ISS for the manner of their reporting, they did also release a full disclosure release, and a suitable, working patch within 36 hours of the issue going public.
I don't see many vendors responding that quickly, although, to be fair, the apache team did know about the vulnerablity already.
It's all about the "Window of Exposure" really. Go to Bruce Scheiners Cryptogram page to see some excellent arguments about peer review, and the whole window of exposure idea.
The trade-offs:
Pros:
Closed-source: No one can see your code, thus eliminating obvious exploits (buffer overflows, race conditioning, etc.) from being quickly jumped on. Less chance that an external developer will accidentally or intentionally misuse some of your libraries or otherwise write in exploitable code.
Open-source: Everyone can see your code, thus allowing a multitude of additional glass-box testers to help patch things more quickly to adapt around problems a project leader may/may not see. Quick turnaround on patching of code.
Cons:
Closed-source: Limited field of testers; slower turnaround on bug/exploit fixes when even reported (can go on unreported for months, or even when reported, may be ignored or shelved indefinitely).
Open-source: Since everyone can see your code, some black-hat punk is invariably going to find some exploit and blast your distributions for it. Also, QA is nigh impossible to timely enforce when 100's of developers submit patches, sometimes anonymously.
Opinion: Both may seem to be even; however, the timeliness of a fix can make all the difference in security, and waiting days vs. weeks or months for a patch can make or break an information-driven business. Also, even if an open-source project is patched with an exploit ingrained, there will still be a quick turnaround on patching it, as there is for any bug. IANA genius, but at least from a business standpoint, it would seem that quick and usually-reliable beats slow but usually-guaranteed.
Never attribute to Hanlon that which can be adequately attributed to Heinlein.
If he truely said this... Then the report is laughable.
1) Windows is open-source, because the bugs are easy to find. But you can not fix them.
2) He changes all common meanings, so the report can be used as FUD.
Is he a CS major or MS major? (Martketing Science)
I haven't read the paper yet, but I would say that if generally any two particular pieces of software have the same number of bugs or security issues, the open source software will benefit technical server groups more for the ability of those groups to analyze the code and make their own fixes if necessary, and for the way in which the community generally very quickly responds to discovered flaws. Closed source software does not tend to respond as fast or offer the flexibility of allowing users to analyze the code. Of course, I haven't read the paper yet. Maybe they take that into account.
I am not sure how much value this has. There are a lot of other considerations.
With open source you have the source, so you can do something about bugs, you can fix them. And you can also look for potential issues in the code. You are in control of your own security. And a potential attacker has no idea what you've done with your particular implementation.
With closed source you are completely dependent on the vendor to provide fixes. First you have to prove to them that something is wrong, then, if you are lucky, after some period of time, the will provide a udpate which may or may not fix your particular problem. They may not be as motivated as you would be to fix the problem.
I'll take the Open Source choice any time. That way the people who care about security are the ones in control of security, an arrangement that is likely to work better than any other.
But at least "he acknowledged that real-world considerations could easily skew his conclusions. "
Light cup, beer drink, thin so chain, neck turtle fat, man I won't say it again
In theory, there's no difference between theory and practice. In practice, there is.
Supporters in the Linux community have maintained that open-source programs are more secure, while Microsoft's senior vice president for Windows, Jim Allchin, argued in court that opening up Windows code would undermine security.
The two things are nowhere near the same. 'Open source development' is not at all the same thing as 'closed source development, opened up later.'
People complain about posting without reading, but that's it--if it's from news.com/ZD/etc., it's wrong. :-)
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
All software has security vulnerabilities. Software with vulnerabilites is secure as long as nobody knows about the vulnerabalities or nobody exploits the vulnerabilities. Security is a process, not a state. To run a secure system, you have to know as much about the vulnerabilities as the hackers. You have to patch your systems. You have to manage your risk.
All it takes is one hole in some piece of software that you are running. If somebody knows about it and hacks you you are insecure. There are channels for discussing security vulnerabilities for both open and closed source software. Holes in both open and closed source software get patched. In that respect they are equally secure. There are more holes in both. It doesn't matter how many holes, it only takes one. In that respect they are equally insecure.
While the article is over 2 years old, the logic behind the man's reasonning is still very actual and he raises some good points.
Seriously, all things being equal, wouldn't you want to have access to the source code if you could have it?
Maybe it's more secure, maybe it isn't. I think security depends as much on the humans who set up and use the system as it does the software. But security is just one selling point.
If you don't have the source, you can't modify the code. All you can do is configure. (Well, unless you like hacking binary.) But if you have the source, you can de-bug, add features, remove unwanted features, etc.
And if you don't have the knowledge, skill, or desire to do this on your own, does it hurt you any to have the source available?
There's another sense in which having the source code makes you more secure: you're not tied to the vendor. If they go out of business, you don't have to go shopping for a new vendor who has a similar product that you'll have to migrate to in order to enjoy upgrades, patches, and tech support. If they decide to add features to a new version that you don't like, you can branch the code off and keep your house version however you like it.
There's a zillion reasons to prefer open source software. It's not just about security.
You see? You see? Your stupid minds! Stupid! Stupid!
I'll accept his statement that both are equally secure, especially because it's 90% based on the administrator. The difference is however, an open-source bug has many more eyes upon the code, and hence can be fixed a lot easier. Also, (though this doesn't pertain to most closed-source products) for programs that were written to be platform-independent, all the fix needs to be is a small .diff file, for the administrators who want to be as secure as possible, and the official builds and packages can be released in appropriate time.
The other great thing about OS is you -yourself- can fix the bug. No, not everyone is a kernel-hacker, but theres many bugs in small programs too.
IE: Not too long after I had first installed linux, I found out I couldn't play a certain DVD with any DVD player (Ogle, MPlayer, Xine, etc) although they played all of the others ones perfectly. The program was libdvdread (I believe) was dying on a failed (and completely unnecessary) assert(). So I opened up the sources, commented that line, recompiled, and wa-la, I could watch it now.
So, yeah, there will always be bugs; some OS products may even have more because they're made by people in their spare time (ie: apps like Ogle); but regardless, because there's many more eyes on it, bugs can (and generally are) fixed a lot quicker....
open source software isn't as bug free as we would all like to think.
All this shows is that open source software has had more bugs discovered and fixed than we would have liked there to have been in the first place. It has no relation at all to the number of remaining undiscovered bugs, and therefore no relation to the security of the software in question.
It's simple:
Assumptions:
1) When written, open source and closed source software have on average the same number of security bugs.
Observasions:
1) The number of security bigs in a piece of software only decreases when they are fixed.
2) A security bug is typically fixed after, and as a result of it being discovered. (they can be fixed by accident, but i will neglect this as it's irrelivent anyway)
3) Closed source software and open source software can both have bugs discovered by trial and error style cracking.
4) Open source software can have bugs discovered due the sheer numbers of people with access to the source.
Conclusion:
1) I conclude that open source sofware will tend to have any bugs discovered more quickly because there are more ways to discover them, and all ways available to closed source are also available to open source.
Can anyone fault my reasoning? It seems to me that both start equal on average, but open source will tend to have the bugs removed more quickly.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Most of the time when comparing Closed Sourse Security to Open Source Security Most of the time people want to compare Microsoft as a flagship of Closed Source and Poor security. And they use Linux with all the latest patch or Open BSD which is a model of security. I think it would be more fare if you compared Linux as the OS and Solaris as the Closed Source. And check the security for those two in that case you may find less of a gap. Using Microsoft as a judge of anything is really giving closed source a bad name sience they only make junk.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Comment removed based on user account deletion
I personally run an open source perl portal... Don't worry slashcode, I'm not competing with you :)
Just recently, a new developer came on board, and really studied the code. He successfully found about 10 odd / abstract ways to exploit the code.
I might be an ok programmer but I NEVER in my life would have found these. It's just not my specialty....
Without the code being opensource and open to viewing by others, I never would have thought to look for these types of expoits, and they would have remained in the code. And if someone, with malicious intentions, tried them... I would have been.. in short... screwed!
NOW...
Two things happened here to require secure opensource programs. 1) I was willing to quickly make the changes.. and not just quick patches, but really study the code, and look for the best way to fix it.
2) I had a good samaritan.... He could have been malicious, and had his way. He didn't.
I personally believe that both are required, and then yes, open source is more secure and will always be.
www.slightlycrewed.com - Because aren't we all?
Closed source can have fewer bugs (security bugs are merely a special kind of bug) if the company that does the development is discplined and puts the focus on the quality (i.e. minimizing the bugs) of the software. Because they are all in the same organization, and they all follow development standards and methodology and provide good QA testing. That is, if the market and marketing department and the bottom line allows them time to do things correctly, which often is not the case.
Open Source software often depends on a somewhat less uniform and disciplined (but can often independently more disciplined than their commercial counterparts). There is usually less formal organization. This is where it really depends on the quality of work of the people working on these projects.
Because Open Source projects are less sensitive to the market and the bottom line (in general, except for the projects undertaken by commercial entities), they are not as likely to have quality problems because of lack of time.
But to say that Open Source projects have less bugs because more eyes are looking at them is a pretty big assumption. Just because more eyes can look at something doesn't mean more eyes will. The bugs can stay in Open Source projects for years before someone finds a problem - in this case, I'd say it depends on how popular this project is and how attractive is it to people who will look at code and look for problems and can understand what to look for.
If anything, in a short-cycled, less popular piece of software, a commercial software can have better quality than an open source one if the commercial developers are disciplined and dedicated. It is simply a matter of time.
He's a well known and highly competent researcher in the security area (especially smartcards).
He also has a penchant for self-promotion, so the "Marketing Science" suggestion is perhaps not too much of an insult...
The SCO lawsuit makes me wish my company were in Utah. We need a new building.
There are essentially two approaches to security: Proactive and reactive.
Good coding, auditing and QA are proactive. They are expensive, boring, take a lot of time and you are never sure that there's nothing left that slipped through anyway.
Which is why most code, both free and proprietary software, relies mostly on reactive security (though they will always pay lip service and often more to at least good coding).
In proactive security, there should be little difference between free and proprietary software, as the bugs are found and fixed before the product gets shipped.
Free software shines in reactive security, however. The blinding speed with which bugs get fixed is impressive.
I found that Mozilla overflow that made the news recently, and it took the Mozilla team about a week to come up with a fix. My experience with commercial vendors is that it'll take them a week to come back to you and ask for more details. If they give a damn at all.
For example, there are critical bugs in IE that have gone unfixed for months and are still there. That outlook==worm problem won't go away this century, either.
It's not the number of bugs that counts, it's the severity and the speed of bugfixes. Give me 10 light apache bugs that are fixed within the week any day, but keep that 2 critical IIS bugs that take a quarter to fix.
Assorted stuff I do sometimes: Lemuria.org
Is he a CS major or MS major? (Martketing Science)
I'll leave it up to you to decide what the "BS" stands for.
Nope, no sig
Is there a real valid reason for this type of document to be in PDF form?
Have you looked at your HTML translation? The formula's and stuff at the end are unreadable. To really have done it in HTML they probably should have been rendered as GIF's.
The paper was probably prepared in LaTeX to begin with. From there it's easy to put it into PostScript or PDF. Frankly, if you're going to be doing academic work, especially work involving lots of formulas, LaTeX is the way to go. Easy to create, really sharp looking, and readable.
I have been running an ISP now for two and a half years, using Linux and FreeBSD exclusively. In that time, the following items have cropped up that I had to fix:
1. Bind hole (root exploit at the time, now it's chroot'd and running as named.named)
2. ftpd (root exploit, I turned ftpd off)
3. telnetd (root exploit, turned it off, too)
4. openssh (root exploit, simply recompile of new version)
5. current Apache bug, which even if it's an exploit is far from root or anything else useful
That comes down to a problem to be fixed every 6 months or so. This is real world. It doesn't matter a rat's ass to me what all shows up on Bugtraq, what matters is if someone is going to be able to hack my boxes. Most of the "bugs" aren't going to leave me open to remote exploit.
Given that, it's ludicrous to say that my setup is no more secure than a Windows/IIS setup. IIS updates come out weekly, sometimes requiring reboots. I literally don't have the time that it would take to run Windows here.
And IIS is probably the most-hacked piece of Windows. Want to compare it to Apache? Apache runs as nobody.nobody on most systems, or perhaps www.www. How about IIS? Hack Apache and you're an unprivileged user who'll have to rehack the box from the inside. Hack IIS and you're the Administrator. Even if Apache was as exploitable as IIS, it still wouldn't be as big a deal.
Michael
Do you have ESP?
Look... why is it that highly paid movie editors who poured over Spider-Man for many months with millions of dollars, couldn't find what the movie viewing public did in the opening weekend? According to movie-mistakes.com:
That sound remarkably familiar to Eric Raymond's Cathedral and the Bazaar? When Spider-Man was checked for bugs by the highly paid editor (programming team) and none were found, did they not exist. Is the movie inherently more flawed when the bugs were found and reported by the viewing public (open source programmers)?
Toddlers are the stormtroopers of the Lord of Entropy.
This understimates the ease with which some people reverse engineer closed software for living. As a result the "applying a new abstract attack" example is completely bogus. If you know how a vendor thinks, writes and generally does things then you can apply the attack very soon after its release. It is not significantly more difficult then applying to an open source application. There are other such things as well.
Otherwise a good read. But the fact that it is written in a where reverse engineering is not a flourishing business definitely shows.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
"In theory, theory and practice are the same, but in practice they're different."
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Mr. Anderson's paper is only thirteen pages long. A quick review of it shows extensive use of anecdotes and stories. As I learned in High School, the first step of the scientific method is to pose a hypothesis. It seems that he has barely made it past this first step. I say this because his paper appears to be pretty thin on real research. He may have one example with TCPA, but what about all the other open systems? In the end, he may or may not be correct. But let's wait for his peers to have their say in his hypothesis.
Look at mozilla. Its a great project but its not as nice as IE by a long shot. Anyone using 1.1a in Linux will know that [e.g. me! while at the same time 0.9.9 works fine... ???]
I know this is subjective, but I disagree and think IE isn't as nice as Mozilla. Mozilla 1.0 is smooth, much nicer than IE. I didn't think I'd care for tabbed browsing, pop-up disabling, image blocking, and themes but I really have grown used to these things. The only complaint I have is I haven't figured out a way to sort my bookmarks. I've used 1.1alpha and it is buggy, but it is an alpha release and shouldn't be compared.
Now the security of Mozilla is something that we don't know too much about (or do we?). We all know about IE's security...
I have a theory: I think open source software is found to be more insecure in the early stages of its development, whereas closed source software is found to be more insecure later in its development. For example, Linux was considered a very insecure OS about 6 years ago, you didn't run it if you cared even a little about security (FreeBSD seemed to have been the choice for secure x86 *NIX). At that time, we didn't hear too much about Windows NT's security (or maybe I wasn't paying attention).
Things have changed, now people call Linux a secure OS because it has already exposed many of its vulnerabilities, but Windows is known as the insecure OS because its flaws are poping up all over the place. I'm not saying either are more secure (because you can only make an educated guess), but the open source model allows for discovery of vulnerabilities a little quicker and easier than closed source.
Wouldn't you be better off thinking of them as equally insecure?
I see even classic Slashdot is now pretty much unusable on dial up anymore.
"... why do my Win2k installs slow down to a crawl after a few weeks..."
Windows operating systems re-configure themselves without telling the user. Bill believes he knows better than you.
I find bugs and insufficiencies in open source software. But generally open source software impresses me as an attempt to do a good job.
In contrast, Microsoft software seems just sloppy. For example, Microsoft's Internet Explorer has 18 unpatched security bugs (when this was written). These active security risks are different from the recent 15 that have already been fixed. This is sloppiness, not mistakes, and I don't find anything like it in the open source world.
In case the
By the way, when Windows becomes slow because it re-configured itself, try this:
Closed source programs are typically not free. If a bug shows up in it, will you have to wait until the next release for the fix, and will you have to pay for it it you don't have maintainence?
Not to sound cheap, but sometimes it can be a PITA to grab some funds & do the usual hoop jumping to get a purchase order cut. And it
can take a *long* time, depending on the approval channels.
With Apache, I had our webserver updated in a few minutes of reading the announcement of the fix.
-asb
If you look at the article's references, you'll see that "The Cathedral and the Bazaar" is quoted along with "Opening the Open Source Debate" from the Toqueville Institution ...
Just because Microsoft doesn't publish their source code,
.sig
doesn't mean the source code is not available.
Crackers aren't afraid to decompile code, or use social engineering to obtain it.
Non disclosures mean nothing to someone who is writing a virus.
But it does stop the white hats.
That asymmetry makes a big difference in the analysis.
In open source the white hats and black hats are on equal footing.
In closed source, the black hats have an advantage somewhere
between alpha and 0, depending on how hard it is to obtain the source.
Historically, it's been proven over and over that obtaining the source is much easier than the original designers thought,
which is the reason security through obscurity is treated with such derision in the crypto community.
Most bugs are found by people running the code.
Most security holes are found by people who are looking for them.
Since Black hats have no real difficulty obtaining the source,
"Closed" source gives them a huge advantage over their white hat counter parts.
-- this is not a
Software, as written, is just going to have a number of bugs proportional to the amount of code. The number of security holes is proportional to the number of bugs, with some constant depending on language and programming style.
Then there's testing and debugging. It seems to me that essentially nobody just goes through open source code for fun, trying to find bugs; people who look at the code generally join the projects. So, in either case, the team writing the software is also mostly the team that tests it. So you'd expect about the same results.
The security advantage to open source is that, if you really care about security, you can examine the source yourself and determine how good it is, to the best of your abilities. With closed-source, you have to trust whoever wrote and tested the software, since you can't do it yourself.
Of course, almost nobody cares that much. Of course, you can probably bet that if the NSA doesn't change something in the version intended for government agency use, it's right. (Even if the NSA were putting in holes only they know about, they wouldn't leave any pre-existing holes)
The TCPA is basically a boot-loader system that enforces code-signing, using hardware assistance. It's a lot like the XBox boot system, the one that keeps you from running your own programs on an XBox.
Copied from the abstract of the article:
"However, there are more pressing security problems for the open source community. [Read human community.] The interaction between security and openness is entangled with attempts to use security mechanisms for commercial advantage -- to entrench monopolies, to control copyright, and above all to control interoperability. As an example, I will discuss TCPA, a recent initiative by Intel and others to build DRM [Digital Rights Management] technology into the PC platform. Although advertised as providing increased information security for users, it appears to have more to do with providing commercial advantage for vendors, and may pose an existential threat to open systems."
The article says nothing sensible about bugs in software. The article mostly discusses issues surrounding efforts to increase the reach of monopolies.
I suspect that you can generalize this to security, as well. OpenBSD focuses on security, and it shows. Microsoft doesn't, and it shows. This is not a matter of proprietary v. free.
remember, there are no security 'bugs' if there are no attacks.
a bug implies an imperfection in the code that occurs without any outside pressure.
that being the case, because new bugs get 'created' all the time, the real measure of security is time to response since before the attack existed it could not be protected against.
in this respect open source is much more secure due to the sheer volume of people who are able to respond. whether it's the original programming team or some hobbyist in zimbabwe, your chances for a quick response are much greater, not to mention you might fix the thing yourself.
If one adhere to the authors thinking (which for a very long time has been adcocated by Micosoft and other commercial software companyes) that it are impossible to create 100% correct programs and one only concern oneself with the time period that a securoty exploit is known than the author are mostly correct.
... well just say that thay maybe should change operating system ASAP.
However if you want a truly secure system you want a system that is proven to be secure. If people shall trust Internet and it's services one need a truly proven secure Internet - in that regard the author is way off and the paper is really unimportant since it talks about a situation that should be purely academic.
The only way to prove that a system are secure is to release all specifications (ie. source code) and let everybody try and break the system. If noone has broken the system in a couple of years the system is very secure.
With closed source you can never prove that the system is secure by pounding at it... because it may exist a security hole that only is easy to find if you have the source code.
It only takes a disgrountled employee to release the source code (ot just the exploit) of the closed-source system and you have a nightmare.
If you want to have a truly secure system - use proven secure software.
This is why algorithms for crypto are released so that all crypto experts can try and break it. This is similar to when ESR says that given enough eyeballs any bug is shallow.
It is possible to write computer programs that are 100% correct. But the only way to ensure that, is to matemathically prove that the program is correct. It exist an academic programming language called Pro that was created for just that purpose - to prove that a computor language are 100% correct according to it's specifications.
So in theory it is possble to make 100% correct computor programs. The only way to make sure the proof is correct is to also make sure it's secure in practise by letting other try to find errors in the proof. Thus the only way one can get a 100% correct program is the release the source code.
In practice thare also exists programs that have been proven to be very secure - because the developers where concerned about security - one good example are qmail.
A different example is Microsoft who recently said that they can't release their source code because it will threathen the USA security. Deep down in Micosoft software exist at least one unexploited security hole. It only requires one person to find it or one former employee of the houndred or maybe shousends Micosoft employess who knows about the security hole to tell others about it.
If you are using Micosoft closed softeare you are now sitting on a ticking bomb. So anyone interested in a secure system should not use Micosoft software. Since it it well known that there exists a security hole in it that will compromise your security when it is becomes public knowledge. So anyonw concerned with security and uses Micosoft software are
With open source I know that if anyone has seen a problem it is fixed - for closed source I know that the company will probably not fix it until an exploit is widely known.
If one wants to be taken serious whan talking about secure software one need to show that the software is secure and not just talk about security and treat is as an PR problem.
Just saying it like it are.
While the Mac Classic may not have been rooted, it was also not designed to provide 24/365 network services, multi-user protection, etc. Linux is generally designed as a Unix clone, which was generally designed to provide services to multiple users, either via shells or served some other way over the network (web server, database, thin client server, etc.). In order for Linux to offer this, it has to provide the ability for some people to have access and not others. Any time services like that are offered with selective access, security problems exist -- it's a natural part of trying to identify entities -- everything can be spoofed at some level. Hence the mantra, "Nothing is ever totally secure."
The Mac Classic (as far as I know) does not offer a web server, network databasing, remote shells, etc. If it does, the Mac OS (9 or before that the Classic runs on) is not stable enough to provide these service reliably: there's no memory protection, and there's no way to log in remotely to fix problems. If those services were provided on the Mac Classic, you would have seen remote root exploits happening.
Another way of putting it -- what can you do on a rooted Mac Classic? That's like somebody rooting my watch. There's nothing to do with my watch once it's been rooted, and in any case, my watch doesn't really offer the ability for remote control, much less a root environment versus a non-admin environment. Whoever's sitting at my watch (or whoever my watch is sitting on) has control, and there is no other option.
Also, root exploits are not the only exploits. Crashing a computer remotely is an exploit also (one thing root exploits are used to achieve). Even if the Mac Classic does not offer a remote shell (as far as I know), how hard is it to crash remotely? I worked in a Macintosh computer lab, where the Apples went down constantly because of bad network data. We sometimes couldn't put particular protocols on the ethernet because OS 6/7 couldn't handle it. I suspect that if people tried, it would not have been that hard. (I'm not anti-Apple -- I think that most every kind of computer has appropriate uses).
Since Mac OS X offers the afore-mentioned services, I suspect that if its use increases, we'll start to see remote exploits happening. This has nothing to do with it being Unix based -- it's a result of what I said before -- any system which offers services or grants selective access based on an identification can and will be exploited.
If you're asking about an out of the box installation, then Mandrake is more secure than Windows. Mandrake's installer runs a few scripts to stop unnecessary services, close ports, build an appropriate firewall, and otherwise lock things down. The user is prompted for a low, medium, or high level of security. A brief description of each level is offered, so even a clueless user can make the right choice. The user hits a button, and the system does the rest. It's point-and-drool simple, and it works.
Windows does none of this. Everything but the kitchen sink is installed and running. It's hard to tell what's running, especially if you're not familiar with Windows' cryptic names for all the services. There are no good explanations of what services really are or what they do. Everything is buried 3-4 levels deep, and poorly organized. Unless you're already familiar with it, it's much harder to figure out than Mandrake.
So yes, Mandrake is more secure. Part of this is the installation itself- it goes through the appropriate steps to build in some security. The other part is general usability. Mandrake wins here, too.
Don't get me wrong, not all Linux distros are as good in this respect. IMO, Redhat is about as bad as Windows, though it's getting better. Others might be a complete disaster.
same goes with the typical e-commerce vendor, who if misses a day of availability needs someone to either sue, or to have fix it.
That comment is a little inaccurate. When was the last time that a software company got sued for downtime?? I can't think of one instance. Seems to me that most corps and govs that run IIS do so for two reasons:
1. Slick marketing
2. The old "no one ever got fired for buying MS argument.
Where's my lobbyist? Right here.
Seems to me that neither OS or CS is any kind
of guarantee of security -- holes can go unnoticed
in OSS for years, and holes can be found in CSS
without having the source at all.
What really matters is *how easily and quickly
the holes are fixed*. Seems that OSS has CSS
beat on this issue hands down.
-- jfh@cise.ufl.edu
His analysis is based on a mathmatical modeling of the processes.
I'd say that open source does a better job of actually delivering on the promise of security.
This article does point out that it can be done, so MS has no reasons not to do a better job.
The only fault is that you assume open source software will have more "bug testers" (ie, anyone with access to the source) by default. In theory, that's not known before the fact. I have to imagine Eudora has more people working on and testing their mail client than Columba (an open source mail client on sourceforge) does. Just because it's closed doesn't mean there are less people working on the piece of software, and therefore has less people that can fix bugs.
But practically speaking, I think you're on the money. What it boils down to is what people do when they do find bugs in the source. I think M$ would like you to think people will use this open book to start hacking. It would appear that most people bothering to look at open source projects would prefer to submit a patch than to exploit the security bug.
As long as people patch and don't exploit, and as long as we hold our dicussion to popular open source products and their closed peers (like Apache vs. IIS rather than Eudora vs. Columba), I think your arguement holds.
Post script...
Note that it also helps that open source projects tend not to toss legacy code out the door as often, afaict. Once a bug's gone, it's gone, so to speak.
It's all 0s and 1s. Or it's not.
I've found this to be rather true when is compares to comparing Open source vs Close sourced. When it comes to comparing your big name software, open source takes a lead in security. I guess it has to do with more people poking their heads in the code. There is almost a total reversal when it comes down to small programs. Even custom work. I avoid OSS at all costs. These smaller programs don't get much exposure and hense are usually full of holes and bugs and a rarely ever at V1.0 status. I have had much better luck choosing closed source products in this area. I guess you get what you pay for here. Just my observation.
Since the PDF article isn't /.ed, I suggest anyone interested read it anyway.
However, I dispute your claim above. The article is well-reasoned (far better than most of the naive counterposts here, many by people who clearly haven't even read the article in question and know precious little about software security research). It is written by an established researcher in the security field (by whom I happen to have been taught, some years ago, so I can vouch for his authenticity). The mathematics provided and the reasoning behind it are supported either directly in the article or in the other cited material, and much of it has been subject to previous peer review and accepted as sound.
So come on, Futurepower(R)... Do tell us not just that he's wrong, but why. Right now, you're just throwing blind criticism at a well-reasoned and supported piece, for no apparent reason.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The flaw I see in your reasoning is the assumption that the methods of discovery which are common between open and closed source software will find an equal number of bugs.
Taking Microsoft as an example (although their reputation isn't that great), they have been reported to use 1 dedicated tester for every dedicated programmer. This isn't someone who just uses the software and plays with it a little, this is someone whose job it is to look at the design and actively figure out ways to crash the machine.
Your average open source project, or even high profile project doesn't have anywhere near this number of dedicated testers because, quite frankly, it's not a fun job. Sure there are plenty of people who use the software for their own uses, but proving something works for you is not stressing the boundary conditions any more than the average user of closed source software would stress those conditions.
I would suggest you look more closely at the typical development cycles for open and closed source software and note that there is reason to believe that in some cases close source software may indeed be less buggy than open source.
The "many eyes" theory does help open source, but whether it makes up the difference of having an army of paid and somewhat dedicated testers is an interesting area for debate.
Fear: When you see B8 00 4C CD 21 and know what it means
One fundamental difference is that it's perfectly reasonable for a Linux distro to lock down everything by default, so that you've got to make some changes before it's usable for much of anything. (You could play solitaire if the distro included a program...) If you bought Linux, you should know or learn a bit about administering.
Windows, OTOH, starts with the assumption that a complete idiot will be installing it. If networking is crippled by default, it will probably remain crippled until the user returns the computer because it "won't do X". And it makes the almost-reasonable assumption that with an idiot setting it up and using it, the box won't contain anything worth a good cracker's time. And these assumptions are almost OK; the problem is that (1) when the box is used for something serious, it's hard for even a professional administrator to keep up with all the changes needed to make a system secure, (2) they've made the home system default so wide open that serious crackers can take over hundreds of them at a time and use them in assaults on important targets, and (3) MS is so sloppy that everything is a lot more exposed than they intended...
"Do tell us not just that he's wrong, but why."
The mathematics is absolutely stupid! The author assumes that bugs are a random event. But they aren't. Bugs are heavily influenced by sociological factors that affect the outcome by more than a factor of ten. A lot of the bugs you seen in Microsoft Internet Explorer, for example, come from the sloppy practices of programmers who are not particularly interested in what they are doing and who are pushed to a tight schedule, so when they see that something needs to be re-written, they can't re-write it, because they don't have time.
Remember when Microsoft released Windows 2000? Someone inside Microsoft said that there were still 63,000 bugs (or known shortcomings) in their database. There was no time to finish the job, and Windows 2000 and Windows XP are still quirky. I just reported a bug in Windows XP, again, which I first saw in Windows 98. All of those operating systems re-configure themselves without telling the user. The company just doesn't care enough to do a good job.
Bugs in software are caused by social factors that we cannot measure. Some programmers write far tighter code than others. Compare the security bugs in OpenBSD and in Windows. OpenBSD is far more secure because the people who control it say they want it that way. Microsoft just announced a greater interest in security, but will the company actually devote resources to fixing the code? That's a sociological issue for a company that has always put money first.
It is impossible to test reliability into software, or anything! Reliability is due to design decisions, or the lack of them.
The author says,
"Reliability growth models seek to make this more precise. Suppose that the probability that the i-th bug remains undetected after t random tests is e-Eit. The models cited above show that, after a long period of testing and bug removal, the net effect of the remaining bugs will under certain assumptions converge to a polynomial rather than exponential distribution. In particular, the probability E of a security failure at time t, at which time n bugs have been removed, is [Equation that Slashdot cannot display: E = 1X i=n+1 e-Eit ~~ K=t] over a wide range of values of t. I give in the appendix a brief proof of why this is the case, following the analysis by Brady, Anderson and Ball [7]. For present purposes, note that this explains the slow reliability growth observed in practice."
He is just pulling your leg, and probably his own. Note the word "random" in the second sentence. In mathematics that is a technical term, a precisely defined term, and it doesn't apply here.
The author is just grabbing attention, and it worked. Now he has something to put on his resume, an article in CNET (by someone who doesn't understand the mathematics, but assumes that it must be okay, because it looks so impressive).
Show me the equation that has a term that explains the difference between OpenBSD (Five years without a remote hole in the default install!) and Windows XP (zero seconds).
Give the source code of Internet Exploder to the OpenBSD coders, and we will see how random bugs are. They could do what they already did with BSD, examine the code for poor practices, and re-design the parts that need it. Then all the "randomness" would stop happening, as if (in the view of some) by magic.
Observation 5:
Several people are paid to peer review closed-source code full time, and these people are paid and trained to specifically look for security bugs. The Open Source movement lacks this feature, where large chunks of code can go unreviewed forever if it's not sexy enough. Additionally, if you don't know how to look for security bugs, you don't see them even if they're right in front of you. It's just not a matter of looking for static buffers.
Observation 6:
Closed source software generally isn't as closed as you imagine. For example, the Windows source code is available - under rather strict terms, of course - to a number of large customers, government bodies, and universities. These bodies in general, and universities in particular, generally review the code quite meticuously. So (at least in the case of MS, which is usually the favorite target), I don't see your observation holding all the water it intends to.
True. Also note that the defrag program in Windows 2000 and Windows XP does not defrag all files. Some will be left with literally hundreds of fragments. To get true defragmentation, it is necessary to buy a third-party defragmenter, like Diskeeper:
http://www.execsoft.com/diskeeper/dkvsbuiltin/dkv
However, program files should not be fragmented in a month. I doubt that the fragmentation of data files would cause significant slowing in only a month.
All this is empty theorizing. Is there empirical evidence which demonstrates whether open source or closed source is more secure?
I agree with you. However, this seems an unlikely answer for the person who posted the comment about the issue. Windows re-configuration occurs when there is some kind of problem or merely a change hardware for example. Windows will pick a new configuration without telling the user. Then, when the hardware is added to the system again, windows may not pick the correct installation, causing numerous hard-to-troubleshoot problems.
I just came upon an example of re-configuration. A drive in a removable hard drive drawer was replaced with one of identical make, model, and size. Windows XP Professional re-configured the paging file from drive F: to drive C:. It did so with no message to the user. The system is faster if the paging file is on another drive besides C:. This is the sort of thing that sells Linux.
You're ignoring the general point about open vs closed development, and picking on MS instead. We know they write crap. That is not a reason to criticise closed development in general.
How about R = nrH
where R is the rate of finding bugs overall, n is the number of bugs available to find, r is the rate at which one person finds each bug and H is the number of L337 Hax0rs trying to find the bugs.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I'm not ignoring any point. I'm saying that the sociology is so important that all other factors concerning software reliability are small.
How this works....
On open source:
Look over the source code and find a defect. Make sure it hasn't been discovered and patched and make sure it's in use.
Use it... then lose it...
Once you've used it enough times a system admin will report it. He may even fix it himself.
Once reported using the source code track down the program that caused it. Swap out the buggy program for an alternitive until a patch comes in.
Poking around dosn't work as your user box isn't going to be as secure as your target computer.
How this works on closed source:
Decompile or if your a terrorist who can afford expensive wepons just liccens the source from Microsoft.
Or you can poke around.
As only a sellect few have the source the target sysadmin can't fix it.. swaping programs will cost to much so that's not an option.
Your best bet is to find an ill planned feature. Software companys are reluctent to remove features even when they compramise security. So your crack is likely to continue to work for a very long time.
In the past larg companys wouldn't use a program or operating system if they couldn't get the source code. They want the ability to fix the code if a defect is found.
I don't actually exist.
I have plenty of reason to believe it isn't, from my own personal experience. For a start, we're considering a product, not an individual programmer. As an aside, we now seem to have switched to considering the creation of bugs rather than the creation of security flaws -- i.e. design flaws that allow penetration even when implemented to spec. The creation and detection of bugs, though, depends on many non-linear things. For example...
These, and many other similar effects, could all give rise to a massive degree of nonlinearity in the rate of bug creation. Perhaps more significantly still, the testing strategy must focus on the correct areas at the correct times to maximise bug detection. If you attempt to follow a uniform testing strategy throughout the lifetime of a project, then you will simply not detect bugs as well at certain points, and hence the rate of bugs that slip through will be higher at those points.
It is certainly not very clear that this is the case in general. If you take a mainstream application, like Linux or Windows, then it may be so. If we open-sourced the proprietary development we were doing at my old office over the past few years, no-one else other than our competitors would check the code, because no-one else would care. And you can be damn sure that your competitors aren't going to dutifully submit bug reports. Please stop equating "open source" with Linux, Apache, and other widely-used and popular toolkits. The article was discussing closed vs open in general, and its conclusions are general conclusions. Specific examples that happen to start from different initial premises -- notably, "this is a product of wide interest with many people who may be willing to contribute" -- obviously may not follow the general rules, but that doesn't make those rules any less correct in the general case.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The sociology: Commercial software authors often write under difficult conditions. They are often forced to release something with which they are not happy. Open Source authors have no other motivation than to do a good job. Everyone who is interested will see their code, forever. The sociology makes a huge difference.
With Microsoft Windows XP, for example, some of the deliberate design is adversarial to the user's interests. There are more than 12 ways that the OS expects to connect to Microsoft computers.