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
At least with Linux there's a pretty good chance of getting things fixed, where in 'some other OSes' they wouldn't even get to see the source code...
To Terminate, or not to Terminate, that's the question - SCSIROB
yeah! it's much better to work with unknown bugs than already known ones
I guess it's more of a buisness decision than reality based decision anyways..
The greatest right given is the right to be wrong...
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.
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.
1. you should write portable code. Your code security should not depend on the OS security.
:)
2. For embedded applications there are many other OSes apart that are most suitable for the job. i.e. ThreadX for a lean, fast OS and VxWorks for a more comprehensive version.
3. I dont udnerstand how a simulation on a desktop machine can be security-compromised. (For an embedded device, look at [2]). Will hackers d/l all your data? how will the udnerstand what it means? In the end, if your simulations are so sensitive you can put put them in an isolated network.
Just my 2 euro-cents
I miss my rubber keyboard.(Homepage)
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.
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.
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
Security Deathmatch!
Linux vs Windows....
Sendmail vs Exchange
Apachve vs IIS
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
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 guess you are right to a point. I got a little agitated and shot from the hip, when I first read the ./ post and skimmed the article.
I do maintain though that OSS is more secure. Even if it had ten times the amount of security bugs that closed software had, I could at least rest assured that I will know about the bugs and be able to make an informed decision. In a closed source implementation, I am always left guessing.
That is just my humble opinion though. Thanks for your post; made me realize how much like an idiot I sounded earlier.
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
...not as nice as IE by a long shot. Anyone using 1.1a in Linux will know that...
Just out of curiosity, how do you run IE on linux?
And is it really fair to compare IE with Mozilla1.1a, an alpha-release of mozilla, which is aimed at bugtesters and developers?
And how do you make the comparison with IE on windows and Mozilla on Linux?
You are not entitled to your opinion. You are entitled to your informed opinion. -- Harlan Ellison
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.
And is it really fair to compare IE with Mozilla1.1a, an alpha-release of mozilla, which is aimed at bugtesters and developers?
:-)
I think so considering that both products are still in the unstable development phase with a lot of bugtesters
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
"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.
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.
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.
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".
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.
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.
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.
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.
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
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 :)
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...
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.
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.
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.
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
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.
Well I am comparing my "IE in windows" to "mozilla in linux". IE supports the HTTP standard better, it doesn't die as often [assuming you have a clean install of windows... something not so easy] and generally just is easier to use.
I find even Mozilla 1.0 will die on a page or two [mostly at yahoo] and just hang without anything. In windows with IE I never really had any problems.
And trust me when I say IE supports HTTP cleaner. I'm in the midsts of writing a web server and in due course I have tested it against wget, opera, mozilla, voyager, konquerer and IE. IE handles pretty much all of the HTTP specs [that my limited server uses just fine]. IE will also properly handle invalid replies [e.g. with no Content-length].
Opera is somewhat closer but doesn't use keep-alives [despite the fact it sends the request!]. Opera doesn't use consistent capitalization of HTTP traffic which at first was a pain [my server jsut lower cases all the traffic for simplicity].
Voyager [from QNX] just sucks.
Mozilla works somewhat decently but I find it won't handle all cases of GZIP messages [I actually submitted a bug w.r.t this].
Tom
Someday, I'll have a real sig.
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.
Well I am comparing my "IE in windows" to "mozilla in linux". IE supports the HTTP standard better, it doesn't die as often [assuming you have a clean install of windows... something not so easy] and generally just is easier to use.
What HTTP-standard is that? The "Real" HTTP-standard set up by W3C or Microsofts HTTP-standard?
Obviously mileage vary when it comes to Mozilla, because I haven't had it crash on me once in Windows. Never. It happened once in IRIX, something I reported to bugzilla and that bug was gone 1 month later.
I find even Mozilla 1.0 will die on a page or two [mostly at yahoo] and just hang without anything. In windows with IE I never really had any problems.
Can you give some examples of pages where mozilla dies? Does it happen everytime you visit those pages? Have you reported this to the mozilla-team via bugzilla?
And trust me when I say IE supports HTTP cleaner. I'm in the midsts of writing a web server and in due course I have tested it against wget, opera, mozilla, voyager, konquerer and IE. IE handles pretty much all of the HTTP specs [that my limited server uses just fine]. IE will also properly handle invalid replies [e.g. with no Content-length].
I believe you. In mozilla you have to write proper http/html for it to work, not Microsofts bastardization of it. Yes, the redmond based company has embraced and extended this protocol too. I would very much like to know how Mozilla handles the invalid replies that you spoke of.
Yes, IE is much more forgiving than Mozilla. This is not a good thing. That encourages webmasters to write bad code. If you should complain about something it should be about the persons who write bad html that don't comply to the w3c standard.
Mozilla works somewhat decently but I find it won't handle all cases of GZIP messages [I actually submitted a bug w.r.t this].
I agree. Mozilla is a good product, it isn't perfect. It isn't "done". It's a good product in the making.
It's good that you filed a bug-report. That is actually very constructive, and a lot of people could find this useful. Thank you.
I use Mozilla because it's a standard compliant cross platform browser with lots of features that IE misses still. I'm sure they'll catch up, but until they do Mozilla is my browser of choice.
Best regards
.haeger
You are not entitled to your opinion. You are entitled to your informed opinion. -- Harlan Ellison
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.
I believe you. In mozilla you have to write proper http/html for it to work, not Microsofts bastardization of it. Yes, the redmond based company has embraced and extended this protocol too. I would very much like to know how Mozilla handles the invalid replies that you spoke of.
Yes, IE is much more forgiving than Mozilla. This is not a good thing. That encourages webmasters to write bad code. If you should complain about something it should be about the persons who write bad html that don't comply to the w3c standard.
See now you are just trolling. You say "mozilla is ___so____ much better, etc..." have you actually tried to write an HTTP daemen?
You got it backwards about the errors. IE won't accept quite a few HTTP errors [aka bugs] that Mozilla will [or opera will]. The HTTP implementation in IE is actually quite a bit better than you make it out to be. For example, IE will request and make proper use of GZIP encoding and HTTP keep-alives. Mozilla will request both but not always make proper use of them [it always uses new sockets for HTTP requests regardless]
Don't believe me? Download
http://tom.iahu.ca/iahu.zip
With mozilla 1.0 or 1.1a [just verified]. It will not be a valid zip file because Mozilla will request the server to send a GZIP data stream and not decompress it. Now try it in IE. IE will request GZIP encoding *and* decompress it.
So unless you actually sit down and write a server stop telling me the way things "are". That just makes you look stupid and you lend less credibility to the whole OSS scene which is a bad thing.
Tom
Someday, I'll have a real sig.
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!
See now you are just trolling. You say "mozilla is ___so____ much better, etc..." have you actually tried to write an HTTP daemen?
I have no intention to troll. None whatsoever. And please don't put words in my mouth. I never said that quote you have above.
No. I have never tried to write an http-daemon. What does that have to do with anything?
I tried to download the zipfile you posted and as you said, it works fine in IE but not with Mozilla. I have no idea why this happens but I'm sure the mozilla team does. You have filed a bug-report so that they can fix it, right?
Why does this happen from your webserver and not from other servers that I've downloaded zipfiles from? Is it really a Mozilla error? This is an honest question, because it really seems to work elsewhere.
About the bastardizaton of html. It's no secret that Microsoft has added new tags and stuff that only works in IE. Pick up any book about web-design. In most of them it sais right there [Only works in IE].
Although I can't prove it, it wouldn't surprise me if they did the same to the http. They have some authentication-scheme that isn't a part of http don't they?
Just because I haven't done exactly the same things like You it doesn't disqualify me from having an opinion. Especially if its backed up by some facts.
Here they state that Mozilla "may be the most compliant of all current browsers."
Here they say something similar. Written in 99 they haven't tested the 1.0 release and aren't all positive. But they agree that it complies with standards.
Another link about how well Mozilla follows standards.
So, in conclusion I'd like to repeat what I said before. Mozilla isn't perfect, but it's my browser of choice until IE implements the features that I find useful in Mozilla [Gestures, Image/popup-blocking, tabs among others] and prove to be faster and better (subjectively decided by me) and can be run on the platform [OS] I run at the time.
Best regards
.haeger
You are not entitled to your opinion. You are entitled to your informed opinion. -- Harlan Ellison
I have no intention to troll. None whatsoever. And please don't put words in my mouth. I never said that quote you have above.
..." which means it accepts messages encoded with GZIP or at least thats how Mozilla and IE interpret it.
No. I have never tried to write an http-daemon. What does that have to do with anything?
Yes you did say it [or at least someone with your account]. I copied the msg verbatim.
I tried to download the zipfile you posted and as you said, it works fine in IE but not with Mozilla. I have no idea why this happens but I'm sure the mozilla team does. You have filed a bug-report so that they can fix it, right?
Why does this happen from your webserver and not from other servers that I've downloaded zipfiles from? Is it really a Mozilla error? This is an honest question, because it really seems to work elsewhere.
Yes I filed a bug and its being worked on. Yes its really a Mozilla error and yes, you probably haven't seen it elsewhere because most HTTP servers don't support the full "TE: gzip" specification [mine does].
Here's the outline of the bug
1. Mozilla says "accept-encoding: gzip,
2. The server replies with both "content-encoding: gzip" and "transfer-encoding: gzip" which means the data being sent back is a GZIP encoded message
3. Mozilla mistakes the fact that you are saving a ZIP file with the fact it shouldn't gunzip it. So basically Mozilla asks for GZIP encoding but thinks because its a ZIP it shouldn't decompress it.
IE gets the system right where it will ask for GZIP encoding and decompress it too.
About the bastardizaton of html. It's no secret that Microsoft has added new tags and stuff that only works in IE. Pick up any book about web-design. In most of them it sais right there [Only works in IE]
Thats a moot point. As long as IE supports the standard HTML it doesn't matter if it adds-on to the standard. The point is HTML 3.2 documents should load in IE like they do in Mozilla. If the user chooses to use IE extensions thats hardly IE's fault!
Tom
Someday, I'll have a real sig.
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.
It works fine in Galeon(Version 1.2.5).
War is not the answer. War is the question. NO is the answer.