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.
However, due to the possible weapons applications of our work, security is a big issue. So in 2001 the Feds came in to audit us. When they saw we were using Linux they almost shit a brick. Apparently the GAO (General Accounting Office) has done a lot of work checking the kernel code and has found many many security errors and is recommending that sensitive sites not use the bug-riddled OS.
I tried to tell these guys to have the GAO just submit patches to Linus, but they told me to install Windows 2000 instead. *shrug* What're ya gonna do?
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.
Less peer review actually improves scientific accuracy
Fewer engineers lead to safer cars
Oh well, at least we can wait for the amusing PR spins that MSFT can put on this.
Finally, some has the balls to tell the truth rather than just regurgitate the propaganda.
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.
Does a week go by without some "researcher" claiming to solved this dilema?
For the life of me, I can't imagine how closed and open source programs could be equally
secure simply because there's no quantitative measurement to prove that. Even if there was, it would
be so unlikely... Notwithstanding, I believe to generalize this issue at all is just mental
masturbation -- security depends on the development context -- just because something was
developed close/open-source just doesn't make it any secure or less secure by definition, it
doesn't make it equally secure either.
I'd still lean towards open source, because there is an element of truth there.
i.e. "nothing to hide"
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.
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)
All software wether open or closed source is created by humans.
We're *ALL* allowed to make mistakes, aren't we?!?!?!
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.
A few quick quotes from the paper:
Other things being equal, we expect that open and closed systems will exhibit similar growth in reliability and in security assurance.
Even though open and closed systems are equally secure in an ideal world, the world is not ideal, and is often adversarial.
The problem is that in an ideal world, there would be almost no bugs anyway. It completely overlooks some of the factors in proprietary software that cause the bugs. Items such as deadlines for a product can actually encourage sloppy programming (Compare Mozilla 1.0 with Netscape or IE's early releases).
One poster on ZDNet said it best: "In theory, there is no difference between theory and practice. In practice, there is."
There are several secure closed source operating systems (Trusted...). Don't just think as far as windows wrt closed-source operating systems.
I do not represent myself.
yes, open source programs have bugs too, but the thing is that they can be (and really are) fixed very fast. In the closed source world you have to wait for the bugs to be fixed often in a few months (if lucky), while open source code is fixed in a short time.
it is more flexible an develping time decreases a lot. You can obtain new versions almost every week.
For example:
How many kernel_fixes/version have the Microsoft Windows Graphic User Interface?
xDDD
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.
I hate PDF files, so I converted the paper to html, and posted it Here.
Is there a real valid reason for this type of document to be in PDF form? Not to mention it is 122k vs 44k for HTML.
Squash
I'm not sure that anyone who isn't a zealot believes that open source software is bug free. Open and closed source software are, after all, both written by humans of varying ability.
But I think they're looking at the wrong stat. What should be compared is how long users of that software are forced to live with the bug.
That is a much more meaningful question.
My
Limekiller
Come from a collaborative effort on the behalf of the many devlopers to patch the vulnerabilities once they are discovered. Sure, that's just as easy to do in a closed source enviroment, but when you have multiple devlopers in multiple time zones all hacking away at the same time, communicating over the net, it becomes a lot more easy.
Another difference application security makes is the popularity of the software. Obviously my little not apache linux web server hasn't been compromised because it only represents less that 0.005% of all webservers. IIS, while representing less of a market share than Apache (Netcraft), is more of a target because of the fact that their are used by highly desireable corp's and govt's. Govt's are more likely to run IIS because they are somewhat important and their needs to be a source of responsibility for the software they *purchased*, 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.
All that said, their is still the human-admin factor. As we have seen very recently -- both IIS and Apache are prone to being vulnerable to attack, it's the response time of the developers and the competency of the admin to roll out and apply the patches/upgrades. There was a story on here earlier (month or so?) regarding the weakest security link in IT being the employee's, but the same holds true for lazy admins. It's not entirely the product you use, but the level of knowledge you have regarding the product, and your competency in making the service secure.
dmarien
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 don't think we should look at Open vs. Closed Source, but rather the manner in which they implement security. If the manner which the security is implemented, open or closed source, then it will be secure. Look at the manner in which it was impleneted, not whether you can see the source or not.
Great Linux Site
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
The funny thing about the situation is you'd think open source software would have more bugs, being that anyone can find a hole in the source code and then exploit that. While that is true for the most part, security is more dependant on the firewalling and server configuration itself. However, for security "in general" i think open source and closed source software are pretty well matched. Open source software allows you to find the bugs in the code, which means there are less but still a few hanging around. Closed source software seems to have more open holes *cough*M$*cough* but are thus harder to find by the "security through obscurity" clause.
- tristan
I was wondering if the common consensus is to actually do testing in an almost double enviroment. One where the source is availible so that "expected bug checks" (bugs which are obvious on the source level like arrays that do not bounds check in C, type checks, etc,etc)and one were the source is not availible for view so that the tester will try things that are not in line with the code (If I press this button with the mouse while moving the window to the left and saying the magic word...totally contrived but the meaning is there) ?
What exactly is slashbotting?
You see? You see? Your stupid minds! Stupid! Stupid!
Security Deathmatch!
Linux vs Windows....
Sendmail vs Exchange
Apachve vs IIS
I lost the count of how many times M$FT has argued that this is not true
there is no way to accurately say how secure closed source and open source software is, also i must remind everyone before this turns in to a Windows vs Linux (and general *nix) debate that BOTH OSes have open and close source products, i support linux but please no preachers and people turning this into a war of Windoze vs *nix :-)
:-)
:P) :-)
note: even with the above this comment will stink of win vs *nix
an example of IIS vs apache for instance
security problem with IIS is found, if you publicise it M$ will shit a brick and do their absolute best to play it down and keep it quiet, if you contact them directly they'll keep it quiet for as long as possible and tell you to do the same, its also likely they'll take ages to fix the bug
whereas with open source apache if a bug is found yes it gets publicised quickly, by everyone, and its likely to get fixed ASAP, iss did a sloppy job by publicising it with a fix before even telling apache and then finding out the fix doesn't fix it totally, still apache got an updated release out in less than 24 hours
now back to just open vs closed, danger with open source is that some1 could spend ages analyzing the code looking for an exploit to use maliciously and not publicising it so it doesn't get fixed until after alot of damage has been done, but it is almost guarranteed (not sure of spelling) to get fixed and fixed FAST, with closed its that they are likely to be very slow to react if they react at all
just my 2 pence (im british
No, it's not a game. As the riots after some of the games would indicate, it's often a way for two groups of people, "us" and "them", to run around for a couple hours to prove that our dicks are bigger than theirs.
It used to just be a game. More of a religion now.
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?
--I do not know the application specific programs you require in your research and work. But however, wouldn't it have been more prudent, when choosing OS's, to have gone with mac classic in 98 as the "most secure" by empirical observation? I am saying this based on known exploits at the time, ease of use, etc.
This is NOT a troll by the way. I am a relative newcomer to linux, and am using it learning it as just a hobby, but by my personal anecdotal, it doesn't even come close to being secure without really tons of research and specialised knowledge, wheras mac classic just worked admirably using a default install. I never once got rooted using a normal install, despite many years on the web. With linux, even trying different firewalls so far (repeat, I am still a n00b here), I honestly can't say that (unfortunately). I know it's possible, but it wouldn't be my first choice for a 'secure' OS, again, especially going back to 1998.
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
So fixing a bug 24 hours after it is found by the developers (open source) is as insecure as fixing a bug 1 month later after it is found by an user or cracker (closed source)???
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
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?
Bug Free != Secure.
I can write a perfectly correct (i.e. "bug free") piece of software, and it can be wide to compromise.
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.
In situations where your software has to 'hit the ground running' and stay running, the 'Audit model' works best. An open source model does not provide it because it waits passivly for some one to come along and find a fault, the it waits passivly for a fix.
Where as if you design code within an audit model you are accountable for each thing that you do and how it may fit something like a 'use case' and 'threat profile'.
This is not a perfect solution either but if you have effective auditing then you generally get reasonable stable code out the door first time up..
Open source people think that their model is the be all and end all of development especially where security of a crypto system is concerned.
From personal experience most software to do with crypto systems is generally only analysed by people who, 1. Want to copy your code into their application. 2. What to disrupt your crypto system to some degree, be that either trouble making or a full break.
The Open source model gives a slow audit that over time will and fix things.. A proper audit will fix it before you cause people grief..
I'm sick of hearing about Open Source -vs- Closed software. Open source open source open source. Don't you have anything better to talk about?
Lets face the facts people: Commercially developed, proprietary software is better for most things, and always will be! Why? Because the people writing it get PAID to. Capitalism won, Communism lost; The 1900's are over. Wake up and smell the Nabob!
Some of my ex-friends are open-sourcies ( I say Ex because I refuse to talk to them after learning about their disease)-- Even they admit that their open source crapola (ie: Lex) doesn't come close to my proprietary masterpieces ( ie: MSDev Studio IDE, Delphi IDE, MS Word, NOTEPAD).
Get a grip! Support a programmer and go BUY some good, working software, instead of trying to STEAL it and claim it as your own invention.
Have a nice day, unless you're using Linux,
Will
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/
A good analogy is automobiles (somehow it always is). To be safe, be a good driver. No question about that. However, being a good driver isn't enough if you buy tires that suddenly blow out. You also need a safe machine.
Furthermore, it's not realistic to assume that all admins can be pros. I wish they were, they should be, but the small-business person who sets up a few machines on a shoestring budget can't be expected to be an expert LAN admin *and* also good at whatever his/her business is. Like it or not, people set up computers and LAN's under those conditions. Thay'll gravitate towards the systems that support that environment the best.
Finally, I believe that in the long run, Linux will encourage professional administrating *more* than Windows. With Linux it is easier to buy a shoestring-budget support contract. A small business can set up a few Linux boxes and hire a pro to administrate and update them remotely. The support people will need to make very few on-site calls, and have fewer bugs to fix overall. It's just easier (ergo cheaper) to admin Linux.
Miko O'Sullivan
The GAO did a fine job finding the bugs, but were too mired with regulations & procedures to submit them. That's really too bad. It would go a long way in solving the problem.
Does the GAO get special access to the Windows 2000 code? That code would really kick ass if they did!
"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.
Slashbotting (from my own personal dictonary): The act of mindlessly regurgitating the popular rhetoric of open source preached on this site.
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.
The author is assuming that you start with n bugs and you systematically stamp them out, so the total number of bugs is constantly decreasing. I saw an interesting study on bugs in some large system (IBM?) years ago that concluded that past some point, the number of bugs started going up again, because "fixes" were introducing more problems than they were solving.
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:
His argument about MTBF basically comes down to this:
How many bugs you see during a period of time is less important than the period of time you spend.
By this argument, I can make the MTBF of Windows 3.1 to be a million hours by having a million people sitting in front of the screen doing absolutely nothing for an hour!
Here's a different way of looking at it. Open source has *two* groups of testers, those who look at the source code and those who don't. One hour's testing by the first group should be the equivalent of N hours by the second group, where N is some constant > 1. Closed source only has the second group. Thus, by altering the t rather than the lambda, you get increased testing time for the open source.
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.
I can't disagree too much with the article, but the open vs. closed security debate seems to always focus on a very narrow view by assuming security concerns are only focused at the present version. The unfortunate reality is that the world is littered with many old systems doing real and valuable work. Special purpose systems are especially prone to being kept in service many years after the base technology is obsolete. Substantial components of those systems can often be closed source, and hence, unmaintainable after time. There is a Windows 3.1 system within a few hundred yards of this office still going strong. I hear the laugh, "Just upgrade it!" It would be a six figure project to update it to a modern version, as tons of very custom code would have to be converted and tested, including drivers for custom hardware. A critical flaw surfacing in the vendor supplied portions of such a system will never be fixed. On the other hand, I can still patch a RedHat 5.2 system. So which is more secure in this sense?
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.
not to be redundant but this guy is WAY off base.
i mean in all reality the person who wrote the report doesnt seem to have a grasp of what security really is. it is about many things not only the amount of "bugs" in the software. but also the quickness of a patch becoming availible and weather a bug goes public or not. i mean apache has an exploit everyone can see it AND/OR work on a fix for it. windows IIS server has a bug and who knows about it? who can work on it? does it go public? if so how long til it gets fixed? weeks ? months? never?
i am just going to stop before i start ms bashing again
"Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe." --Albert Einstein
I conquer that open and closed source start out equal buggy. However, open source may have more advantage then just the number of eyeballs. In particular, there no need for a "rush to market".
Since most open source projects are given away for free or little cost, there less need to work long hours, less temptation to cut back on testing.
Open Source usually doesn't have a marking team and/or managers who make unrealistic deadlines forcing the development team to spend long hours and when they still can not make the deadline, releasing an unfinished products while there advertising "the most stable version ever".
Open Source can afford to take more time, recommending people stay with the older version instead of answering every support question with "you have to upgrade to the new version".
Without closed source software, we wouldn't have fine products like IIS or Microsoft-DNS.
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.
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.
If your poster children for open and closed source are, say, unpatched Redhat and MS Windows, you might well conclude both have goodly numbers of bugs. If your poster child for open source is OpenBSD, where there is a culture dedicated to making it secure, you make open source look better. On the other hand, if your poster child for closed source (not all that closed actually since listings are fairly available) is VMS, where there is also a culture dedicated to making it secure, closed source starts looking pretty good too. The culture that produces particular code is IMO much more important than simple open or closed-ness; it influences strongly the number of sets of eyes that look over any given set of code. That is also true where you have proprietary code that is nevertheless available for inspection, as people outside the companies producing it can and sometimes do notice and report bugs and cause these to be fixed. A company that does not let wide audiences see its code produces thereby suspicion that the reasons for this have to do with issues of ownership (edited disassemblies? They would show.) or other features they are ashamed of...but does not lead one to think they are hiding security holes especially. Most such do not leap out to the eye.
I rather liked this quote in his conclusion: "The real future tensions between the open and closed system communities will be defined by struggles for power and control over standards." Realistically, it's people like Slashdot readers who are waging the rather useless "ground war" of open vs closed debate. Vendors control what happens, and if you think customer demand has a serious effect on vendor action, look at Microsoft, or any of the the other loathed, despised, and hugely succesfully vendors of hideous software. It's just like politics: you can debate all you want with your peers, but it's the folks in power who make the decisions, and they could give a rat's ass about your opinion.
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.
If everybody in the world suddenly stopped hacking and bughunting. everything would suddenly become "secure". unfortunatly that's never going to happen, because everybody is in it for the "fame".
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.
Any software that is developed is susceptable (sp?) to the same issues, and it all comes down to the abilities of the programmer. The advantage to open source security is in (generally) improved response time in a distributed environment. Here's an interesting article that points out some of the ways that open source can be affected by 'security through obscurity' that I hadn't seen presented anywhere else.
For those who thing that closed source and open source software are equally secure I have one word: OpenBSD.
Wait a minute. The third paragraph says this:
Which brings us to the inevitable conclusion that there must be an unusually large number of flaws in closed-source software simply because of the number of reports that come out about those flaws. Either that, or one of the motivations for choosing a closed-source model (protecting the reputation of the developer by limiting information about flaws) is in error.Why do I say that? A quick survey of CERT® Summary CS-2002-02 reveals that at least 4 of the 7 alerts mentioned in it are in closed source software. This gives them about 57% of the notifications (for our admittedly small sample size, but I'm no statistician). With closed-source still claiming the lion's share of security issues, you have to conclude that they, had far more than 57% of the total number of issues during the same period unless their attempts to conceal flaws was completely ineffectual.
Food for thought.
-Joe
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
Most Open Source programs, at least at the user level, are considerably simpler than some of the snakier Windows programs.
Where is the multimedia equivalent to what DirectX offers?
There isn't one.
Multimedia on the freenixes sucks. Bigtime.
That is just one example.
Freenixes are good at doing stuff that has been known and a stable area for a decade or so.
It takes a skilled specialist programmer to get them to do anything more elaborate.
A Windows machine, on the other hand, you drop in some binaries and away you go.
It is written by an established researcher in the security field
How can you say that? Everybody knows that there are only a few established 'security experts', mainly Schneier. He hacks crypto which makes him a security experpt. Ask him, don't be relying on these crackpots who probably are being paid by the government to pretend to be 'security experts.'
This is an interesting idea.. and I agree that open and closed source are almost equally secure. What does this mean? The amount of public vulernabilities discovered is just about the same. Open source is better, because it contains less problems, however. Closed source software probably has tons of vulnerabilities just waiting to be discovered. Even Microsoft admits it :)
what about if u have the source for the closed source programs, and you have the source for the open source programs. do you think that the programs that are open source would be more secure because people can find stupid mistakes and fix them easily but with closed source u have to try a shoot and miss to catch security flaws... *sum up - if people got their hands on closed source program's source it would probably be more vulnerable... right?
I don't know why this guys needs to write a paper on this. There's not secrets about the differences between open source and closed source security.
... open source. There are probably more known (read as written... *known*, not found) bugs in open source software because of online bug tracking systems like BugZilla et al. We all get the impression that closed source is less secure (I think like that too) because the only bugs we hear about is the big M$ security holes, especially on slashdot. Reality is that there are probably just as many security flaws occuring open source software, we just don't hear about it as much because not everyone's suscribed to the 10 000+ project mailing lists on sourceforge :o)
The number of bugs found (please read exactly as written... *found*, not known) is probably equal. Even though I'm totally for open source, I wouldn't go about saying that open source hackers are 10x better than closed source ones so I'd imagine it's about the same skill-wise. There may be more people hacking open source software, but there's probably more hours put by each coder in closed source so I'd approximate it roughly to be about the same. Result? Assume (realistically) about the same amount of skills and man/hour put into software.
The big difference is obviously that open source bugs are
Crackers all know where to find information about security flaws, that's not the problem. Where it really matters is how fast you fix those major security flaws. I think this is where open source shows its superiority.
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...
...if the next time someone found a big security hole in IIS, they publicized it right away like the ISS assholes did with apache. Then see how quick M$ gets a fix out. 24 hours? I'd bet against it.
The OSS is insecure, a propertity system will always be secure especially when stock options are an issue.
One thing that never seems to come up in these debates is how truly "closed" closed source is. If you take security through obscurity seriously, you'd have to run Microsoft like it was the Manhatten project. Consultants would have to be carefully screened. Employees would not be allowed access to the Internet. They could send email only within the company (otherwise they could email themselves any source code they'd like). They would have to be searched when entering the building and leaving, so they couldn't smuggle code out on diskettes or printed out on paper. Maybe they would have to work on diskless workstations.
It's pretty obvious that no company in the real world is like this, so we can assume that the Black Hats can see Windows source code. And of course there is the famous "shared source" program that makes Windows code available to colleges, etc.
In the open source and free software world we don't have the false sense of security that those in the Windows world may have. As far as I can tell this should make our stuff more secure in practice.
The more important point is one still pretty much undebatable by empirical evidence:
Closed-source, proprietary systems possess the means to hide their deficiencies for as long as possible.
If a cracker discovers a hole in closed-source software, and exploits that hole, the vendor (read: Micro$oft..) can easily ignore the issue until enough evidence accumulates in public forums that a problem *does* exist.
As a recent example of this, see the Handler's Diary entries about the recent M$ SQL vulnerabilities.
This vulnerability was confirmed by a group of dedicated security people who had nothing to go on but what they could see happening in packet traces, after noticing an odd increase in traffic on tcp:1433.
If they had had source code available, the process might have been much quicker...
t_t_b
I'm on PJ's "enemies" list! Are you?
The item I found interesting (relating to the TCPA) was:
Once the machine is in this state, Fritz can prove it to third parties: for example, he will do an authentication protocol with Disney to prove that his machine is a suitable recipient of `Snow White'. The Disney server then sends encrypted data, with a key that Fritz will use to unseal it. Fritz makes the key available only so long as the environment remains `trustworthy'.
The question, it seems to me, then becomes "So how far does this 'trust' extend?" If a trusted machine downloads 'Snow White,' and then serves it out to a hundred 'untrusted' machines, how trustworthy is the initial trusted machine? How much code is a new machine going to be saddled with just to prove it? Or can it be proven at all (to the degree that'd be required for the TCPA to work the way it's supposed to...), short of essentially having to pay Disney (in this example) to have someone come out and certify a machine as "trustworthy" (potentially every time a download is initiated)?
Sounds like a boneheaded plan to me...
Internet Explorer was unable to link to the Web page you requested. The page might use standard HTML or CSS.
... Microsoft do list their bugs online (ever heard of the Knowledge Base)?
Few other closed source suppliers come remotely close to this - some try, a bit, but they just don't put in the investment.
OK, the KB doesn't answer everthing, and you have to Google usenet sometimes, ie at the end of the day you can be reduced to using the only resource that is available for tracking open source bugs.
In Building Secure Software, Viega and McGraw assert the same thing. See chapter 4, On Open Source and Closed Source.
I know for a fact Microsoft pumps serious donations in Cambridge University. That is worth considering.
my favorite:
"If you boot up your PC in an untrusted state, it will be much like booting it with Linux now: the sound and graphics will not be so good, and there will not be nearly so many applications."
I stopped reading at this point.
Since the slashdot crowd is not well known for following up citations, here's my summary after about 15 minutes reading.
1. If a bug has a mean time T to be found, the probability of it not being found in time t is exp(-t/T).
2. However, making a reasonable assumption about the scaling of all levels of bugs, the number of remaining bugs will only decrease as K/t. This is because over time, the remaining bugs will be dominated by harder bugs, those with larger T.
3. If a particular restriction (eg no access to source) reduces the efficiency of tester by a factor x less than 1, the overall bug rate would be K/xt.
4. For closed systems the alpha testers scale as K/t, beta testers scale as K/xt. But since the overall rate is dominated by beta testers, it is still K/xt overall.
For open systems all testers scale as K/t, which is also its overall rate.
Therefore closed systems will have more bugs than open systems by a factor 1/x.
5. For closed systems it is x times as efficient for attackers to find vulnerabilities as well, cancelling out the 1/x abundance of uncaught bugs.
Conclusion, the vulnerability of both systems only depend on K, a characteristic of the original system, but independent of x, a characteristic of the testing environment.
--
This is quite interesting. I could be wrong in reading it this way, as I spent less time reading it than typing it up.
One additional conclusion that can be drawn from this is that opening up a closed system will momentarily increase its vulnerability by a factor of 1/x, until its overall bug rate reduces to K/t.
"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.
Dude, don't complain about freenixes. They soak up the old technology so companies have to create new stuff. If freenixes didn't exist, then Gates might still be leeching us for Windows 3.0 saying "Upgrade to 3.1"
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
The paper suggests (top of p. 6) that for a system with 10^6 bugs each with MTBF of 10^9 the attacker will see a MTBF of 1000 hours but the defender will see an MTBF of one million for finding that bug that the attacker found.
This logic switches what is being measured. The goal of the defender is to increase the MTBF of the attacker for all bugs, not to find a single particular bug.
Investing 10^9 hours into defense will find half the bugs, thereby increasing the MTBF for the attacker to 2000 hours. So, in this case defense is 1,000,000 times as hard, and the conclusion is correct, but the logic leading to it seems incorrect.
I thought the section on the TCPA enabling monopoly leveraging was much more interesting than the open vs. closed source bug finding discussion. If TCPA is made to work, it will surely be severely abused by monopolists just like he describes. Tell your congressman that you want programming to exclude competitor products to be made against the antitrust laws, and that you want to know what he is doing to see that judges that support the antitrust laws are appointed.
I don't really think that the issues of Math that he discusses are what determines the relative security of open vs. closed source. When people know that the source code will be out there it prompts them to code differently, and not imagine that others will be unable to find their algorithmic errors. Perhaps if Microsoft lied to its developers during development and told them it would be released as open source, and then actually released it as closed source, they would be able to be more secure than they are now.
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.
Actually, the typical ratio is 2 testers to 1 developer. Not true in all units, but it's the norm.
To hear Cambridge announce that closed source software is as secure as open source (or, in concrete terms, that Windows is as secure as the Free Unices), is akin to hearing Bill Gates claim that his wife is attractive. They're in bed with each other -- you can't expect 'em to be objective.
Here's the output of 'net start' on my machine.
Automatic Updates
AVG6 Service
COM+ Event System
Computer Browser
Cryptographic Services
DNS Client
Error Reporting Service
Event Log
Fast User Switching Compatibility
Help and Support
IPSEC Services
Logical Disk Manager
Machine Debug Manager
Network Connections
Network Location Awareness (NLA)
NVIDIA Driver Helper Service
Plug and Play
Print Spooler
Protected Storage
Remote Procedure Call (RPC)
Secondary Logon
Security Accounts Manager
Server
Shell Hardware Detection
System Event Notification
System Restore Service
Task Scheduler
TCP/IP NetBIOS Helper
Terminal Services
Themes
Upload Manager
WebClient
Windows Audio
Windows Image Acquisition (WIA)
Windows Management Instrumentation
Windows Time
Workstation
Other than 'Server' and 'Workstation', what
descriptions don't you understand?
To the casual (l)user does 'lpd' seem more or less cryptic than 'Print Spooler'? And if you
can't figure out what 'Print Spooler' does,
here's the description in the Services MMC plugin: 'Loads files to memory for later printing'. Stick a fork in your argument, it's toast.
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.
I remember that Ross Anderson used to work with
Professor Roger Needham FRS, who is now leading
Microsoft's Cambridge Research Centre...
Coincidence?
Hi:
;-)
This has probably already been said somewhere, but let's not forget -- a key point in determining the relative security of a piece of software is sheer volume.
A widely used operating system or protocol implementation is going to have thousands (millions!) of users, and you can expect that almost all bugs will be happened upon, whether they are reported or not (reporting is a big deal). So the security question (i.e. how much damage is done by the security hole) really is, as other have mentioned, how quickly it is patched, and, more importantly, how much scrutiny the code undergoes *BEFORE* it is put into widespread use. In this case, the `experimental' versions of the Linux kernel (2.5.x,etc.) are a great example: they undergo massive scrutiny, but everybody understands that they are buggy code, but we expect the development versions to be better, and errors are fixed before deployment. Win2K cannot claim the same benefit.
On the other hand, an infrequently used utility with a small market will have little effort devoted to finding security bugs, so we can safely assume that under any model, many bugs will remain unfound. In this case, it makes quite a bit of sense, security-wise, to be `close-source' since the sheer effort required to reverse-engineer the code to make a bug exploitable will be grossly disproportionate to the gain of cracking the utility. On the other hand, even if you make the code available, people probably won't bother. As long as it's hard to find the bugs, you could keep the source closed, but again, this won't get you quality software, it just decreases the probability of your getting hacked.
Conclusions: for quality software, use open-source -- easier to find bugs, and more people looking. For secure software that everybody uses, use open-source with an extended security-testing phase. For secure software that only you will use, you need not release your own code
Looks like some eurotrash piece of shit is having an inferiority complex induced hissy fit.
The entire notion, that software engineered in any venue either closed or open is more secure is a dumb question. They both are insecure.
Which software can be fixed more quickly, and can be reviewed for such defects at will and is open to peer review is more important question to ask.
The answer is clear:
Software which can readily be fixed and reviewed quickly is much more robust than software that cannot be reviewed, or fixed only with permission of a DMCA lawyer or court process, or worse, by the manufacture after they take thier good ole time at it...
Not only that, but you cannot review the viability of the fix with closed software.
I am not prepared for example to take Microsoft's word or any vendors word that a security problem doesn't exist in thier software since they patched it.
I won't even go into the secret back doors that disgruntled employees can put into closed software where it can sit for YEARS, with nobody finding out about it. Nobody can peer review it.
Correction, nobody saying it is thier that is vs. Hackers who discover the hole and don't tell anyone about it.
Very very bad. I personally feel security of any product should be open by default, but I won't accept an OS on any of my companies systems/servers if it isn't fully open for peer review by my engineers.
Especially the Operating System.
Those who say Open Source makes it easier to find security problems are right! Thats why the software is so secure, the problems are easier to locate and they are fixed even faster.
If it doesn't make sense from a security perspective to quickly identify and fix vulnerabilities in open software, pray tell how would one fix a closed source/proprietary piece of software?
Answer: You don't and you cross your fingers.
To Which my reply is: Not with my F*cking credit card number you don't...
hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
You know how copyright expires X years after the death of the author, how does that work when a company is the holder of the copyright? A company could live for centuries. Would it still hold the copyright long after any human could live?
All this is empty theorizing. Is there empirical evidence which demonstrates whether open source or closed source is more secure?
1 - Microsoft's code cannot be revealed without compromising security completely, says microsoft.
2 - Open source code can and is revealed, yet OSS is not completely compromised.
3 - With these 2 HUGELY IMBALANCED stances, both have a steady, uniform streams of bugs.
Since bugs are more easily found WITH source code, there must be a category of bugs/vulnerabilities being overlooked in MS code, so it is less secure.
Dear Cambridge... print THAT!
It seems off topic, but there is a term of copyright for organizations. I don't know what it is.
Yes, Europeans are inferior to Africans, Asians and South Americans. But that's all.
I dont know what you that Windows "reconfigures" itself.
The biggest reason that Windows falls a crawl after a few weeks is because the users doesnt crack down hard enough on applications that try to take over the machine. This is applications like: Microsoft Office, Realplayer, ICQ, and many others. By default they register useless and resource consuming services, start various even more useless applications at boot-up and claim that these launches the application faster, but at the same time they consume resources and slows the entire machine down.
If you dont install shit windows doesnt loose momentum. At least I have never experienced that, so you must be doing something wrong.
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.
If it's relevant, and true, what's the problem?
You see? You see? Your stupid minds! Stupid! Stupid!
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.
There is a basic difference between open-source and closed/commercial software which makes open-source fundamentally more geared towards better quality. In open-source projects, publication and correction of bugs is advocated, desired, and always done, BUT in closed/commercial software, bugs are kept confidential and their correction subject to corporate demands. Simple as that.
The whole point of an operating system is that you be able to install things. If you have to not install new software to keep the OS working reliably (for values of reliable approaching epsilon), it's a steaming mound of crap.
Every other operating system can manage this without a problem, it never ceases to amaze me how people make apologies for Windows.
"If you dont install shit windows doesnt loose momentum"
Good god, so you're saying as long as you don't actually use the piece of shit, Windows doesn't have a problem?