Slashdot Log In
Security of Open vs. Closed Source Software
Posted by
michael
on Fri Jun 21, 2002 08:51 AM
from the flame-retardant-suit dept.
from the flame-retardant-suit dept.
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.
This discussion has been archived.
No new comments can be posted.
Security of Open vs. Closed Source Software
|
Log In/Create an Account
| Top
| 366 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Might be controversial (Score:3, Insightful)
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
Re:Might be controversial (Score:4, Insightful)
Re:Might be controversial (Score:4, Insightful)
Many years ago, anyone who wanted to drive a car also had to be a mechanic. Things needed constantly tweaking, they would break down often and were difficult to start and keep running. These days, if someone had a car that kept breaking down, you wouldn't say to them "well, that's your fault. You're obviously not a good mechanic", you'd say "go out and buy yourself a better car, mate".
Don't blame the administrators for the primitive state of current computer technology.
Re:Answer- Mandrake is more secure than Windows... (Score:4, Interesting)
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...
Security Bugs are inevitable (Score:4, Insightful)
Re:Security Bugs are inevitable (Score:5, Insightful)
A flaw is an error in judgement. A bug is an error in coding. The original poster ended his statement that Open Source has lots of bugs. This is unrelated to security unless they are specifically security related bugs.
In any event, the speed at which you can lock down the Fort HAS to be a consideration.
I mean, We have planes flying in Iraq and Afganistan right now. They are being shot at all the time, but they move fast enough to get out of the way. OpenSource moves faster than closed source so I can't possible see how the article writer concluded they were equal.
Equally buggy, yes. Equally secure, puhleez.
Of course not... (Score:3, Insightful)
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.
Re:Of course not... (Score:5, Insightful)
Open source bugs can be fixed by anyone, but closed source bugs need to be fixed by vendors [...]
Correction: open source bugs can be fixed by anyone with requisite knowledge, talent, and time. This would include things such as familiarity with the particular software package, affected platforms, and programming language and the energy and ability to ferret out the bug(s) and apply an appropriate fix. Then one has to factor in that package maintainers may or may not readily allow outside submission (e.g., bigotry, internal/peer review, etc.) of fixes, which may slow, hamper, or block the transmission of fixes. Add into this issues of trust, where a "fix" is offered by someone who lacks proper credentials (official or "street") to someone who has no clue how to evaluate the original issue or the proposed remedy.
Granted, given the nature of open source software, the population of people who may repair a bug may be larger than that for closed applications, but that doesn't force into being an army of people with the inclination or skills to do so, or an effective and trustworthy means to distribute said fixes.
I favor the potential for open source to improve response time to bugs, but I don't think one can claim "anyone" can address issues in an appropriate manner. There's no reason a skillful and organized firm couldn't address security concerns for a closed application it offers with any less celerity than maintainers of an open application.
Security (Score:3, Insightful)
Duh... (Score:5, Insightful)
Another viewpoint (Score:3, Interesting)
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 [counterpane.com] to see some excellent arguments about peer review, and the whole window of exposure idea.
Multics VM/Paging PW Redux and Real World (Score:3, Insightful)
Maybe... (Score:4, Interesting)
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.
Which tend to be patched faster? (Score:4, Insightful)
Oversimplified, abstract, and useless (Score:5, Insightful)
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. "
That should read (Score:3, Interesting)
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.
bugtraq reference (Score:5, Insightful)
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.
Re:bugtraq reference (Score:4, Insightful)
True, but just because they can doesn't mean that they do. One of the great myths about open source is that *anyone* can just dip in and discover a bug and how to fix it. That simply isn't true.
I can find bugs in closed and open source bugs in exactly the same way, by using the product until something wrong or unexpected happens. But just because I have access to the source doesn't mean that I could actually fix the bug.
If you look at projects such as Apache and Mozilla, they tend to have a number of people who know the code very very well and a few that given a couple of hours might be able to work something out and a very large number of people who, in the whole grand scale of things, are of no use at all in providing a fix to a bug.
This contrasts to a large number of individuals in an organisation who know the code very well and work with it day in day out.
Finally let us not forget that whenever people talk about security they often use Apache and IIS as their examples. Be aware that these are not really good examples. Not all OSS projects are of Apache's quality and not all closed projects are of IIS' quality.
You've ended up picking one of the best in the OSS world vs one of the worst in the closed world. It would be a little like compairing Ford's best car with Vauxhalls worst. Just because the Ford won all the time, does it mean that all Ford's are always better than all Vauxhalls?
(I think Vauxhall is Opal in the US)
As always, the answer is..."It depends" (Score:3, Insightful)
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.
A more practical view (Score:5, Insightful)
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
It's Exactly like the Movie Spider-Man (Score:5, Insightful)
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)?
Closed doesn't stay that way. (Score:3, Insightful)
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
security orthogonal to development model (Score:3, Interesting)
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.
Re:security and OS's (Score:3, Insightful)
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.