Slashdot Mirror
Open Source Security: Still A Myth
jpkunst writes "John Viega (coauthor of a.o. Building Secure Software) argues in Open Source Securitey: Still A Myth at O'Reilly's onlamp.com that "open source software may currently be less secure than its commercial counterparts.". According to him, there may be "more eyeballs" looking at open source software, but he does not believe those eyeballs are looking for security problems in a structured way."
... once something is actually found, it's fixed a lot faster than in most commercial software.
Looks like geeks with spelling skills are still a Myth too?
What about more eyeballs meaning a faster fix?
The difference is that when a security hole IS found (whether it be by the good guys or the bad guys), it gets patched VERY quickly compared to commercial software...
Still as much of a myth as "Securitey"?
Curb CO2 emissions: Kill yourself today!
OpenBSD.
Developers! Developers! Developers! Developers!
fnord.
Others will say, "Open source developers are more clued in to security issues due to a better sense of community, and their software is more secure as a result."
He's right. They may not be looking for security holes and they may not find them because of all the "eyeballs" but they will certainly fix them and release a patch to the community shortly after it is discovered.
Now, even if MSFT did release a patch right away it wouldn't make much of a difference as most people don't update their software. The OSS community, OTOH, is still mostly comprised of people that have a Clue and those people generally patch immediately.
So while what the article states is true currently the OSS community does respond faster and with less problems than their counterparts on the other side of the fence.
You're looking at huge upsides also though. THink about the fact that when a security hole is found...there is usually a fix/patch for it within a two days....or less. Not to mention with the vast amounts of people working on the code...security holes and bugs usually get found and fixed on the code side of things before anyone from the outside finds them. When you compare the two markets, there is honestly very little difference in the security of general open source software and general closed source software. Honestly it seems like holes are found more often in software that is closed...
Securitey, it's like 'Security' but with an extra 'e' for effort!
this article looks so much like this trolls post....t hreshold=-1&commentsort=0&tid=172&mode=thread&cid= 10272222
http://linux.slashdot.org/comments.pl?sid=122118&
Corporation's view on security is even less structured.
Actually, corporations are not concerned with security at all ! They are in a business of making money, not secure products.
Now the million dollar question: Who paid this guy ?
Please! The internal groups in MS barely talk to each other during dev cycles, I KNOW they are not coordinating security efforts or we'd see fewer patches coming down. They're weekly right now for crying out loud! Nice structure there.
In the land of the blind, the one eyed man is king.
No 150% more secure.
They believe it, but offer no proof. You don't create an OS kernel by hacking in bits of code, you don't create any complex software by just "hacking" it together. Mozilla, OpenOffice, KDE, GNOME, all the major pieces of Linux software, in my opinion, are very structured and follow a solid design process.
The deal with proprietary software is that someone is on the hook. Developers at commpanies are looking for security problems because they know that if something goes wrong, their a55 is on the line. Teir responsible. OTOH, with open source, who is responsible? If there is a flaw (yes, although is is quickly fixed) there isn't an entity or organization responsible. This is a huge reason why companies like to purchase software. They have clear legal rights, and the other guy is on the hook.
How to Download YouTube Videos
As opposed to the general "closed source" software method of finding bugs/security holes by accident, sweeping them under the rug, and hoping nobody finds them?
I'd go as far as to say that open-source developers are more likely to be interested in security... some corporations certainly don't put it first. Thats a factor regardless of how many eyes are on the code, or how "structured" their search for flaws is.
Microsoft Security - Still A Joke.
-irb
If you're looking for something in the woods and you only have a few people, you have to map out a plan, a structure for searching the woods. You assign people to certain areas, and in this process you make inherent assumptions about your target. You always have specific areas that are searched last, specific areas that are searched by the least skilled people, and specific areas that are searched by people who are skilled but have a specific mindset that colors their search (for instance, they might assume that the object is on the ground).
The chaotic process of OSS is an advantage because it lacks these assumptions. The code is examined over and over again by different people with different skills and motivations.
Line-by-line security auditing is certainly useful, and it's important for areas that need that sort of scrutiny. But for projects the size of Linux or Windows, it's not practical to use that for all code, and a scatter approach with many eyeballs might be better.
It's still difficult to come up with meaningful science on this topic, so any strong statements should be taken with a grain of salt.
I'm going to venture a guess that upwards of 90% of the linux community just assumes that the package they downloaded is secure, simple due to the fact it is open source. They don't look at the source code, because they either wouldn't understand or they just think "Hey, it's open source and popular, therefore someone must have poured through the code".
...." posts hehe.
I'd love to be in charge of a popular project and embed something into the code that isn't a trojan or hack but a simple sentence or two. Something like "Congratulations - you've actually audited this code. Please email me@address for your $50 reward (To the first person only)".
Maybe if we occasionally put these little rewards into the code, people would be more apt to pour through them.
Then again, I'm not a programmer so I'm probably going to get a lot of "This idea sucks because of
Looking for hardware (Currently need: Large Etch-a-Sketch) Have one? See my journal!
Are you serious?
Here a little example.
Question:
How many non-skilled programmers looking at complex security code does it take to screw in a light bulb.
Answer:
Only 1. The one who can look at it, understand it, and then implement a fix for it.
The whole many eyeballs thing is a myth that is more common then the OS security myth (ok that was a bad joke). Really though, can you find and plug security holes in code? Can your friends. OSS is maintained pretty much the same as closed source software, by a team of dedicated people who enjoy doing it. The only difference is that with closed source software the people enjoy the paychecks, with OSS the people enjoy the process.
More eyes does not mean better security in the least, it just means more people looking at code and saying "What the hell is all this"
Be well.
I often hear this claim made by proponents of OSS, but I have yet to see any hard evidence backing it up. Can anyone offer something more solid than assumptions?
"Ask not what your country can do for you." --John F. Kennedy
At the end of the article (I read it for some reason) the author seems to somewhat agree that open-source code is at least equal with - if not superior to - proprietary code. This seems to fly in the face of his initial statements.
This is a common writing technique -- get a reaction based on title and initial statements, and then bring the real argument later on. Just don't walk away thinking this guy is saying open-source code has worse security overall based on the title; that's not what he said.
dmiessler.com -- grep understanding knowledge
and stop with the content-free zen wankery.
And now my old-man is mopping up the peices for his customers who have broken hardware compatabilities etc.
They obviousbly used the same "It works on our box so it must be fixed" approach.
Ripping an new rectum in the fabric of spacetime.
the article is a balanced and well-written one. From the title and summary, I concluded that this was possibly one of those "Rob Enderle" type Microsoft FUD, but surprisingly the author seems to know what he's talking about and comes up with a pretty balanced argument - the above excerpt is one of the examples.
I agree with some of the conclusions/suggestions like a more structured approach and software engineering techniques, but the fact remains that most software hobbyists (the principal contributors to open source software) *firmly* dislike process and red-tape. And they're right, since they're pursuing a hobby, they should be able to do what they like as they see fit.
But then, he's obviously more qualified than the other Microsoft apologists which've written "knowledgeable" articles about open source insecurity.
John Viega is Chief Scientist of Secure Software, and the coauthor of "Building Secure Software" (Addison-Wesley) and "Network Security with OpenSSL" (O'Reilly).
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
Proper spelling in /. submissions: still a myth
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 is the magic number.
That's because their eyeballs are falling out looking at it.slashdot.org.
sulli
RTFJ.
To me the important part of security is the bottom line: How often are you faced with a serious security problem right now?
For whatever reason, open source software hasn't had the same problems as Microsoft for instance. Whether that's because of an oversight on the part of hackers/crackers is beside the point. The point is that based on results open source is more secure.
Potential threats don't crash your servers.
Sure most people aren't looking at security in open source in a structued way, but some people are. Plus, open source can still be better if nobody is looking at closed source security at all. I know where I work, security defects become fodder for amusement at meetings, rather than seious issues to fix.
No I won't say where I work, but it's not MS.
As an IV&V tester (Independant Verification and Validation) I concur with the article. Sure, many eyes helps, but without a proven testing methodology, thought out and complete testing procedures and stylized reporting, bugs/security holes could go unnoticed for a long time.
Any defense can be overcome with enough time and ingenuity. Personally, how much I trust the software (and I trust none absolutely as a matter of principle...duh) has less to do with initial theory/dogma on stability/security as it does with the developer's willingness and ability to take public responsibility for bugs and publish fixes for them ASAP. Of course, if one particular app has constant problems I'll be disinclined to favor it (/cheer Firefox!) but intelligent, unbiased analysis is all too often buried in the marketing hype--with professionals and enthusiasts sharing in the blame.
...won't make it so.
It doesn't matter how many industry-backed/funded books or articles like this are published when time and time again closed software exploits are confirmed later, fixed later, and are often a whole lot worse. It doesn't take much eyeballing to see the facts when they are staring you right in the face.
Problem is that closed-source vendors often have no security. "What the customer does not know, does not hurt them." This type of security through obscurity just does not work.
Don't believe me? What do you think several of those thousands of out-of-work IT people were doing before being laid off. Management sees security analysis and code checking as a cost to cut-out of the budget.
The article fails to consider that, even if open source software has more than vulnerabilities than closed source, those who find such a vulnerability are more likely to publish a fix than an exploit.
Always a godfather; never a god. -Gore Vidal
Hey, would someone point this guy to the "Cathedral and Bazaar" URL.
Some people definitely need to read the basics before commenting on open source model.
Has this guy been working with better vendors than I have? I had to deal with vendors on a regular basis who let some pretty awful stuff slip through QA and some of them could be very defensive about accepting that a bug existed. I had to threaten to shut down multi-hundred thousand dollar contracts to get action sometimes, twice I actually did call bullshit on a vendor and abort the contract.
Money provides a stick to get vendors to fix their problems, but they still have human beings working on their products, and like all human beings they make mistakes, get defensive, have better things to do with their time, etc. Also success (money) can breed indifference in a vendor, once you have a good portion of the market and have people locked into your offerings you have to be just good enough to keep the cost of the customers irritation with you lower than the cost of switching to another product.
[Set Cain on fire and steal his lute.]
The problem, as the author points out, is that many eyeballs do not equal "eyeballs in depth" or "coordinated eyeballs". The housefly has thousands of "eyes", yet that doesn't make it necessarily more visually acute (contrast it with, say, the eagle or the falcon).
I would suggest that, if you are going to code a secure product, that the people and processes that make up the audit team should themselves be auditted. The flowchart of security shouldn't start at the product itself; it should start at the people and processes that produce the product. Otherwise, what you would end up is a lot of people "reaching for the low-hanging fruit" (as the article suggest), making flashy features work, while the obscurer and necessary work get ignored or done poorly. Security must be managed from top down, not invented along the way by coders.
I really don't know how true this is other than the simple fact that I've had a lot better success with Linux security than windows security. But I think this also misses another point - that this is as much about controll as it is security.
Perhaps my house would more secure if only Microsoft managed all the access in and out of it too. But the reality is, that's the kind of controll I want to have - not them. The same is true with *MY* os systems too.
You will respect my securitey!
Apache is a perfect example of this. Patchy describes it very well. While the recent 2.0.51 release shows they are working on finding and fixing some of these problems, it has a long way to go. Microsoft had problems for years with IIS. IIS 5 was a perfect example of how commercial software gets it wrong by letting their marketing people design the system, but IIS 6 is rock solid. It's out for over a year and a half now without a single vulnerability being found. If making your software secure is a priority, it needs to be designed that way from the ground up. Using random bits of code from here or there is not going to cut it.
There's something FAR more important about security than the code, the number of eyeballs looking at it, or even the skill of those eyeballs.
Trust. More specifically doing away with Trust.
I had a minor epiphany yesterday, read about Microsoft's DRM efforts, and realizing what may be fundamentally wrong with their security. IMHO, Microsoft believes that bad security is due to bugs, and that if they can squash their bugs, they will be able to have secure code, AND be able to TRUST the computer that their code is operating on. I'll even let them consider an insecure algorithm a bug, for the sake of this discussion. I think they really believe they can eventually ship sufficiently bug-free code to be considered Trustworthy in execution.
Contrast that with the attitude toward security that has grown in the Open Source arena. No matter how good you get, bugs will *always* be found. No matter how secure you think your system is, *someone* can always get in. Finally, you have to consider *all* avenues of attack, not just the technical/cracking ones.
Some descendents of these attitudes:
Without physical control, the rest of the security is worthless.
Human engineering is probably the biggest security hole.
Consider security as a value proposition, in two ways:
1: Can I make it sufficiently expensive that they'll attack someone else, instead of me?
2: How much do I want to spend on security, and how do I balance that with a recovery plan?
Security isn't a "nail it down, once" thing, it's a process, and includes evolution.
Bugs will happen, so put security in layers, to try and eliminate single-point-of-failure issues.
It's not so much the code, or the eyeball count, or the specific eyeballs. It's the attitude.
The living have better things to do than to continue hating the dead.
He has a point, but there are some flaws in his reasoning. First of all, just because the world can examine the source code of a program, it doesn't mean that people with the necessary skills and knowledge will. However, it does happen. BSD is noticeably absent from the article and anything dealing with open source and code auditing needs to at least touch on it. (But it's dying, I know...) The author also wants us to believe that commercial software has better code auditing software and procedures than open source. He doesn't give much evidence of this, we're just supposed to accept it because they have lots of money and the impoverished open source hackers don't.
Judging from this article, I would doubt that the author has a true understanding of the open source concept. Just because something lacks structure doesn't mean that it's inferior. What really matters is how vulnerable a box is to being exploited. And in terms of real-world metrics, despite much-vaunted 'security initiatives', open source software has a better record of delivering network services more efficiently, reliably and securely than commercial alternatives.
Actually, if my experiences are any indication, most corporate development teams don't have much care for security concerns. There are several reasons.
1) Incompetence. HR departments don't know how to hire coders. They often think a degree means you know what you're doing. Portfolios are rarely asked for, likely because even if they were, the HR departments wouldn't know what the hell to do with them or how to evaluate them.
2) Time to market. Open Source does things when they're ready. Even projects with time-based releases do a "whatever is ready in that time" release, not a, "we're going to do a, b, c in this time." The rush to get to market doesn't leave a lot of time for security and bug fixing. After all, you can release a patch later, after the profit has started rolling in, right?
3) No corporate incentive. The product has a bug or security hole. Unless it becomes a big deal in the media, why bother paying programmer time to fix it? Your customers are already customers. You've already been paid. Without service contracts, fixing bugs just doesn't have any monetary incentive.
4) No programmer incentive. How many corporate programmers have any reason to put any pride into their work? None of the customers are going to know their name, think about hiring them on a side contract, etc. When software I write entirely for Free has a bug, I know my reputation is at stake, and there's a feeling of "how could I be so dumb, I have to fix this and make things right" feeling. I don't get that feeling for corporate work; if they want it fixed, they can pay me, otherwise, the bug can stay and I can get on with my life.
5) Security Through Obscurity. Why fix something nobody knows about? Not only are you not going to get money from your customers for your efforts/programmer-paychecks, you're not even going to get any PR bonuses.
There are many companies where the above don't apply. Good companies have good HR departments that bring in the other developers into the hiring process to select new employees that are actually skilled. Some companies have corporate pride and worry about quality as well as the bottom line. The above problems are not _rules_, they just common patterns I've noticed in my work, and in the work of others.
Rats don't make babiesin a structured way, but there are still lots of them.... especially in New York City.
Simpy
Take the Linux kernel as an example. It is written in C. C is a blazingly fast language and it has many advantages. But it is inherently insecure. It doens't help the developer to prevent for instance buffer overrun bugs.
.net (I think, let me know if I'm wrong), and with that they are protected against buffer overruns. This is not only the case for .net, it is also true for Java (But I know of no OS development in Java).
Large portions of next generation Windows will be built in
The open source process may be superior because of "brute force", but as long as they use computer languages that are harder to write secure applications in, they will have a disadvantage.
The Internet is full. Go Away!!!
I was really disappointed to discover that my favorite service at O'Reilly, the Safari Bookshelf, is run on M$FT products. How might that color their editorial policy regards FOSS vs. proprietary software?
Discussing "the security of open source software" is like discussing "the structural strength of green objects". There are too many projects with different goals and different team cultures.
"What approach do I pick to make $PROJECT most secure?" is a meaningful question. Even more meaningful is "What approach do I pick to make $PROJECT most trustworthy?"
Open source is the answer to both. For a security-critical application like PGP it's imperative to get multiple independent reviews from fresh perspectives. Open source is a necessary but not sufficient criterion for being able to accomplish that.
ooh no, my open source stuff is unsafe! better switch to i.e. and outlook now before its too late!
And in the land of Slashdot, irrelevant clichés are modded +4 insightful. That saying has nothing to do with the article and isn't funny, so what is it?
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 is the magic number.
MOST bugs or flaws that lead to exploits are things that CANNOT be found by using a "structured" method.
Otherwise, you could write a tool that probes for those.
The effect would be that that class of exploit would disappear.
Usually, exploits are much trickier (chaotic, even) than that to find and are usually found "in the field" by actually using the software under a variety of conditions when all the "eyeballs" have failed.
But trying to be controversial to sell a book never hurt...
Move along, nothing to see here.
I don't know the meaning of the word 'don't' - J
microsoft doesnt have structure in its patch rel.....oh, wait
yap
Distros getting users into the habit of typing in root passwords everey time the GUI pops up a window is asking for big trouble.
C'mon redhat or suse or debian or someone.
Please please give me a distro where I don't _need_ to be root to install typical unprivileged packages like upgrading a browser. How about install them under '/usr/local' with permissions where anyone in the group 'local' can install them, or hohw about in my home directory. And yes, I know about "configure --prefix=$HOME". That doesn't solve the problem of not having the benefits of a package manager.
I remember some previous kernel flaws. It was not found by eyeballs but automated flaw finding tools send out by a couple of Linux distribution publishers. This is reality that open source is more secure.
OSS is virtually unencumbered (in theory) by the things that weigh an organization like Microsoft down. For example, if a single developer notices a buffer overflow potential, they can just fix it. It's not like some middle management jackass down the hall is going to interfere and push the change into oblivion.
stuff |
andyet opensource projects have less ecurity patches..
its not eyes alone that make open source secure but the fact that every architecture decision is out in the open to be verfied and quantified on security..
Can anybody think of a better reason why security in opensource is better by some well known measurments such as amoutn of security patche and etc?
Read the sotry about the discovery abotu RSA crypto algorithyms.. it was analyzed and picked apart by quality eyes, right?
so was DEs, if you rember..
the difference between DEs and RSa was architecture decisions.. they got lucky..
In open source we do not believe in obscuring and luck to secure data..
We believe in open source and ebate and analysis toghether with correct architecture decisiosn makes open source secure!
Don't Tread on OpenSource
Heretic! Only unbelievers and heathens criticize OSS! He's a Witch! Burn him! He turned me into a newt!
Very true... I've discovered the same thing myself, and honestly, I can't stand it.
It's sad to see companies just pushing out products as fast as possible to make the best buck, in the end it causes nothing but problems.
Anyone else encounter this with their current employeer or previous ones? I'd be interested to hear the story.
# fuser -v
#
A fast fix is not enough. The notion that it is ok to have exploits, because they can be quickly "fixed" is a cop out. It's like saying, "it's ok to write buggy code, as long as the bugs are documented."
The reality is that not everyone updates their programs or kernel, especially as Linux becomes more mainstream this problem will continue to increase. The only real solution is to have developers program from a "how can I get this done, and how would I exploit what I've just written?" perspective. It's up to the developers to educate themselves on how their code gets exploited - and how to write code that cannot be compromised in similar ways in the future.
So, he say's:
,and of course some guidlines to the end users on how to keep youre system secure (without the hasle and clumbersome intefaces found in today's OS's)
"more eyeballs" looking at open source software, but he does not believe those eyeballs are looking for security problems in a structured way."
I believe security is a major problem for al operatingsytems today. GNU/Linux , SUN OS, Microsoft Windows etc.. . And paying programmers to build OS's does not garanty secure software eighter.
It wil be nice to see a OS that has security embedded not as a feature , but as an integral component of the OS, its policy and workings.
Also a decent security doctrine concering the requirements of installing and building secure applications for that OS
It's just a matter of choice to the Microsoft's on this planet. Eighter continue with the current OS as is and see the consequensec (worm, virusses etc..) or re-think youre OS and put security in 1st place. THis also applies to Opensource, but OpenSource has some nice security features allready build in, but sadly almost never applied.
I personaly think this wil never happen, because insecure OS's at the moment create money, because customers pay it (Windows 95 - Windows 98 etc... )
, and as long as customers keep paying for insecure OS's and there new versions, no one wil attempt to build the secure ones.
"Version 1 of any software should garanty this it is at least secure and fully functional."
Look, I'm not trying to be a knee-jerk, but I'd like a little evidence. A quick search on Security Focus shows IIS and Apache to be about dead even on vulnerabilities. That may not prove that oss is better, but it certainly suggests it's not any worse.
This article is full of speculation on mechanisms, without any real proof. It doesn't even bother to cite the bullshit MS funded studies.
If I want rabid fan baiting with no real evidence, well, I'm on Slashdot already, aren't I?
Disclaimer: MINAA (Mummy! I'm Not An Animal!)
"open source software may currently be less secure than its commercial counterparts"
Seems like crap logic to me. I don't see how he can argue that OSS is less secure than proprietary software given his premises. If his main argument is "even with more eyes focused on the problems, they may not find the security flaws because they're not looking for or trained to find them", then shouldn't his argument be something more like "OSS can be just as insecure", rather than "OSS is less secure"?
Ahem...
I actually think the parent poster and the parent article both miss the point to some extent, though the article is closer to the mark.
Open source is not a magic bullet that will automatically solve all our security problems, as much as I advocate open source software, and open source software is not automatically more secure. The reason why this falsity perpetuates is that people tend to think of security in terms of buffer overruns instead of a secure structure. No development methodology can ensure this secure structure because it is an issue which is either solved in the design phase or not at all.
The question shouldn't be "Can this software be compromised" because you should assume that all software can be, but rather "what happens if this software is compromised." Some open source projects are very good at this, and some aren't.
It is also true that for some projects (like OpenSSL), this question is irrellevant because the primary usefulness is as a library, so the application will have no security itself. But these are the exceptions rather than the rule.
Compare the security of Sendmail (open source) to Postfix (also open source). Which is more secure by design? Compare Apache to IIS. Which is more secure by design? (IIS drops permissions after authentication, Apache does so before). Compare Sendmail's security design to IIS. Which is more secure by design?
Open source is important even from a security viewpoint as it allows us to better understand the architecture of the program we are considering and make educated choices about whether we can run it in a secure manner. However, it is no magic answer and just because something is open source does not guarantee its security.
LedgerSMB: Open source Accounting/ERP
I recently attended a web seminar (webinar) Novell hosted about SuSe Enterprise Server 9 security. They talked a lot about the security certificaitons Suse has been awarded, and how even Micrososft has not been granted the highest level of security for it's 2003 server line. They then presented a poll for the attendees, "Which is more secure open source, proprietary, or a combination of open and proprietary software"? As predicted the combination response won. I think the correct answer to which is more secure Open Source or Closed Source depends totally on what programs are being discussed and where they are applied. Remember just because the source is open doesn't mean it's audited and the people that find security holes necessarily want to fix them. With great power comes great responsibility, as Stan Lee so wisely put.
Novell said in an internal study they found that open source tends to be more secure in popular applicaitons, so Apache is more secure then IIS (as if we needed them to tell us that!), but they found out that in obscure programs proprietary tended to be more secure. This is probably the main idea behinds Novell's recently annouced both source stance. Granted they have financial reasons for not wanting to open source parts of their product line, but this rational does seem logical. Though it would offend the stallmanites.
Stop saying "eyeballs." I can't take it anymore.
$RantMode=on
Computer security means many things, but can be summed up simply as: The protection of the information and physical assets of a computer system.
As a reminder, this means Hardware AND Software security.
As a Real-world security geek, it appears to me that the three worst software issues are:
Please note that "Crackers hacking into your system in order to steal trade secrets" isn't even on the list.
So, no matter which of the top three you care to rant about having security issues in your software, they ALL can be solved with the same two pieces of software on either your own PC, or on a corporate side, ie: Firewall softare (set to deny all unless allowed), and any reasonably competent virus checker (Scan local drives/emails/web pages before loading to the browser)
So, the real question is not which has more bugs, closed source, or open source, but is instead "Why don't more users have those two pieces of software?"
Maybe, instead of beating each other up about security flaws in software, maybe we could all spend some small amount of our time educating the users to get these two packages, and to keep them up to date.
Imagine if a million geeks all spent an extra 15 minutes while visiting their friends and relatives to educate them about this?
$RantMode=off
LongTail SSH Brute Force analysis tool is here!
There are a number of variables involved when one compares the security of software such as Microsoft Windows operating systems to Open Source UNIX-like operating systems including the disparity in their market share, the requirements and dispensations of their user base, and the differences in system design. To better compare the impact of source code licensing on the security of the software, it is wise to reduce the number of variables that will skew the conclusion. To this effect it is best to compare software with similar system design and user base than comparing software applications that are significantly distinct.
The belief in the "inherent security" of Open Source software in a fallacy. Instead, we need to point to a truer means of ensuring the quality of the security of a piece software is high.
OpenBSD
Most notable for the purpose of this discussion, Viega is the creator of Mailman, the fantastically-popular GPLd mailing list management software. All was good and well with his view of the many-eyeballs theory until, one day, he found a huge, glaring, holy-shit hole in Mailman a few years ago. He was so alarmed that nobody had ever spotted this that, after fixing it, he reflected on what he'd learned and turned it into a thoughtful article, The Myth of Open Source Security. As he wrote: Again, Mailman was and is an extremely popular program -- this was not a problem of obscurity.
So, the OnLamp.com article under discussion here is a follow-up to his original article, as he points out in the opening to the new article (but people apparently aren't reading.) As you can imagine, Viega is no rabid anti-OSS guy -- he's, in fact, the very model of what we want our developers to be. He writes good software, admits it when he writes bad software, and tells it like it is, even when we don't want to hear it.
(Disclaimers, such as they are: Viega is an adjunct professor at Virginia Tech, where I attend school, and I was the earliest alpha-tester of Mailman, in the late 90s.)
-Waldo Jaquith
Many of us probably did commercial software development and we know how it's done. Security, right... :( ;)
What's funny though is that the same bosses that oversee the sad state of development in their houses (99.9% of them I guess) still think that, miraculously, software developed by other guys (which are the same but just other) has virtues that no OSS has. I see some psychological complex here
nT!
$(SUBJ). Really - while it is possible to find a hole (to be fixed!) by cracking the binaries, no-one in his right mind would deny that source analysis is considerably easier.
"Better to keep silent and be thought a fool than to open your mouth and remove all doubt."
They make hypothetical statements about broad catagories of open/closed source. In the real world the only software that needs securing are the applications that client/serve on the internet. Then you only need to ask the relevant questions:
Why does apache rule the web?
Why is firefox gobbleing up market share?
Why is the half life of a windows box 20minutes?
I think you'll find that no-one puts themselves on the line for this. Remember the EULA that comes with pretty much any software you can get these day?
Well that basically absolves the company of any responsibility for this.
Now if they have a support contract then someone's on the line to get things done, but support contracts are where the likes of redhat make money, so support contracts for open source can be there too.
Now if you wish to argue that companies have the perception that someone's arse is on the line, then that probably is true, but I hav yet to hear of any company being held to account for security breaches.
He may have some good points, but the "OSS is more secure" argument has been around for a long time; back then, Win95 and NT 4.0 were gaping holes. Microsoft has clearly made efforts in host security since then.
keke.
There are many open source projects. Some are quite secure and others aren't. Some of the insecure ones are projects that a few programmers are doing in their spare time for for their own enjoyment or to share ideas they have had. People are usually warned if a project is stable or not, maybe we should have a security warning as well. That way people won't assume that the project is secure. Ok we have been warned.
Another good example is Kerberos. It's been around a long time, looked at by researchers, students, open source developers, and closed source developers using it as a reference for implementing their versions. Yet, major flaws that weren't subtle have taken a long time to find.
With open source is the same... if you only count as argument about structured search for problems and how commercial software have behind a well organized way to track problems and things like that, you forgot the human factors that in the real wold makes open source more than its commercial counterparts.
Of course, when you put people making a difference against methodologies, you can't do big generalizations as people vary between projects, but at least remains true for the most used open softwares (linux, apache, openbsd, x, etc) against the most used closed source software (microsoft.*)
"structured" is over-rated. Most places that appear to have an organized structure actually are chaos once you look beyond the surface. Look at most law offices, courts, or police more deeply, and you'll find all kinds on "non-structured" things that everyone wishes weren't there.
Is the law "structured"? No, it's a forced, false structure. The real structure is quite different, and involves the gangs, mob, corruption, lies, politics, diplomacy, education, economy, etc.
Code checking doesn't have to be "structured". This idea is that it's checked "throughly" by "professionals". Cost effectively, of course, meaning checked once, or less to reduce costs.
Open source is checked "reduntantly" by "non-professionals" - hackers, hobbyists, and professionals, too - on their own time, they aren't looking to impress the boss now.
I've worked in a "structured" QA lab environment.
Split out all the sections of the program among various people, everyone pounds at it, and says "it's good".
So some QA labs are better and also have multiple coders comb through the code. Not likely, not many.
"Unstructured" means it's not "organized" in that way. It's checked too many times quite often.
Go ask how many programmers write in a "structured" way. A lot of them don't. Their programs can be quite good all the same.
I don't see where that's a problem.
Build your own energy sources from scratch. http://otherpower.com/
The main advantage that OSS software has is not the eyeballs on the source code, it's the ability of the community to guide its development. There's no way for a vendor to take a disasterous wrong turn against the wishes of a broad part of their user base.
If Windows had been open source seven years ago, we would have been able to keep a version that didn't integrate IE with the desktop in use, we would have been able to come up with a clean mechanism to split the useful parts of the HTML control from the dangerous parts, and the majority of the script- and zone- based email viruses and worms that have been plaguing the computer industry for most of the past decade would never have happened, and we wouldn't be waiting for the next attack to hit their daft "security zones" train wreck.
If Apple's LaunchServices and Webkit were open source, we'd be able to split LaunchServices in two and have a separate set of bindings for internet applications, and we wouldn't be waiting for the next protocol-based attack in Safari.
"Most of time" OSS vendors don't test? Wow, way to pull that one out of your ass. Last time I checked companies like IBM, Red Hat and Novell did extensive testing of their products before they shipped them. Not even to mention projects like Apache, Postgresql, Squid, Perl, Samba etc etc. And your proof that most commercial closed source vendors do extensive testing compared to OSS vendors is where? Oh right, your ass again...
.0002 of some small project who doesn't do OSS full time. Yep your right, that's the OSS mantra *rollseyes*.
Name a hugely popular OSS vendor that shipped a buggy product and I'll name twice that number of large commercial vendors who have done the same or worse. Versions of Windows filled riddled with bugs in their "gold" version. Versions of Norton Antivirus that hose your computer if you don't run Live update immediately after installing.
"It works on my box...bug must be fixed!"
Who the hell says that? Oh right lone hacker of version
You have a totally warped perspective of how much testing and bug hunting Commecial vendors do. I've been in IT for 10 years now and if you had been doing it for at least 6 months you'd realize that commercial vendors are no saints when it comes to testing their wares before fostering them on the public and business world. For someone who claims to be from the "business world" your certainly clueless as to how it actually works.
(First of all, I should say that I've spent my career building bespoke systems for blue chip companies in the UK. I haven't been involved in the shrink wrapped product part of the industry.)
The author doesn't discuss the impact that sales, marketing and other corporate baggage has on software.
In every company that I've worked for, senior management work hard to prevent information that could embarrass the company from making it into the public domain. In other words, they tend to deny that they have any security problems unless they are forced to admit it.
Secondly, I'm always under pressure to short change the projects that I work on. Documentation, design, testing, security and reliability always take second place to creating and fixing the features that are most obvious to the end users.
Generally speaking, our customers are not prepared to pay for security and reliability. They seem to think that it's some sort of god given right that comes without any effort. We're almost always forced to bury the cost of these "extras" in the bowels of the project where the customer can't see it.
It seems to me that developers on OSS projects are not usually under the same pressure to hide the real cost of development.
So, as Penn and Teller would say, I call "BS".
HGTTG: "I knew that there was something fundementally wrong with the Universe."
Any questions?
One real problem with open source is that it's really tough to fix a fundamental architectural problem by ongoing patching. If the problem is too big for one person to rewrite in a short period of time, it's unlikely to ever get fixed.
If the Linux world is to become secure, get behind NSA Secure Linux and push. Make apps work within the NSA Secure Linux mandatory security model. That has a chance of working.
While commercial developers may somehow be more "serious" about the product, they are also encumbered by business requirements to be able to dominate the market. One strategy that MS, for example, takes to do this is to tightly couple components (e.g. kernel and browser) that have no business being coupled.
The consequences for this at the security level are a ready-made back door to root privileges.
Decoupling does not guarantee security, but it helps. It is also in conflict with many business requirements of those aiming to take over the marketplace.
--I think we're all bozos on this data bus.
It is the backbone of ... well ... almost anything in terms of getting outside of your own box and was probably one of the first open-source development projects still around today. Yes, before MSFT even existed. Don't freak but I am going to refer a book, in paper *ducks from flying tomatoes* ,
Janet Abbate, Inventing the Internet, Cambridge, Massachusetts, MIT Press, 1999, [ chapter 1. "White Heat and Cold War: The Origins and Meaning of Packet Switching", pp. 7-41]
and this I found while looking for an e-version of the above.
I mean TCP/IP started out as a bunch of academics (paid by the DoD) putting something incredible together AND completely outside of the bounds of modern software commerce and security issues. But had the DoD not trusted these people enough to let them do their work AND share information we would not be having this nerdfest.
*cue the anthem and flag or banner waving of your choice*
In fact this all happened before most of the public and private sectors thought this stuff was really that valuable. Of course, modern commercial entities have contributed greatly to the evolution of both the internet and the applications that support it but isn't it at least probable that the future of software development (and commerce) will be some amalgam of strong commercial leadership and excellent grassroots efforts?
frederik_j_splurdge
I refer you to this webpage, where Microsoft has not fixed a known vulnerability in 123 days and counting. The others were not fixed in a timely fashion either. Show me an OSS vulnerability of similar criticality where it has taken that long.
London's finest organic fairtrade coffee
Even if you do not believe in skills of open source community, at least you can hire your own specialist to look at possible problems in critical code. You cannot do that with closed source, you are doomed to remain a believer of code vendor.
I repeat: You CANNOT be sure you are secure with closed source, no matter what you do. You CAN secure yourself with open source, if you make effort.
There you are, staring at me again.
Since around 1995 most software companies reduced their QA departments and made their end users unpaid QA testers.
QA became a farce and still is!
The problem with Closed Source is that you can't verify what the Manufacturer claims.
-hsx
Funny how these "open source is less secure" people always seem to conveniently forget Apache, which runs the majority of the world's web servers and is open source. Despite its installed base, which is overwhelmingly greater than Microsoft's, it is the Microsoft web servers which frequently suffer from all the worms and viruses.
All these self-proclaimed experts make uneducated conjectures about worms and viruses targeting Windows because that's where the largest installed base of desktops is, but they conveniently ignore Apache. Until someone can come up with an objective explanation for that, any conjecture about open source being less secure will be summarily dismissed.
Tired of FB/Google censorship? Visit UNCENSORED!
Despite what the "religious fanatics" believe, how secure a program is is not whether it is open source or closed source.
It is more dependent on the programmer AND the person configuring it. Look at PHPNuke. Look at djbdns.
Thinking that many eyes can spot security problems is like thinking that a million monkeys can type out Shakespeare.
You need skills and experience, eyes are just a useful option.
The difference lies not in the number of vulnerabilities. All software, open or closed source, will have holes in it. That'll be the case until we have a system in place to write completely bug-free code and a system to insure vulnerability-free specifications (the worst security problems aren't bugs, they're design features which favor convenience over security). The difference lies in what happens when a vulnerability is discovered. In closed-source software, we've seen time and time again that the response by the vendor is almost always to conceal the problem and deny it exists. In open-source software, by contrast, vulnerabilities are almost always published fairly quickly and fixes made available rapidly. That's because nobody is at the mercy of the original author for a fix. The people who discovered the problem can publish a code fix along with the details of the problem. People affected by the problem can patch the code themselves, if it's important enough.
In addition, security holes by design tend to get eliminated from open-source software. In proprietary software, if an insecure design feature benefits the vendor it's unlikely to be removed short of open revolt by the users. In open-source software if there's another way to do it that provides less security exposure and the original author won't change the design, someone else tends to get fed up, make the change and make the patch available. Eventually the original author either has to bow to user preference or find his own version of the software being ignored in favor of one that does.
personally, i found five problems with the 'formal methods' approach.
i thought i'd mention the above to make my point that just because you are structured or the processes you are using is structured doesn't mean that it's automatically better than 'hackage'. after all, Therac-25 wasn't hacked together. it was build by engineers.
what opensource does do for you is that it allow many more people to use it -- and whoever runs into problems can find out why the problem exists -- and have the potential to fix it. "many eyes == shallow bugs" is a very powerful concept. one which the old school cathedral people are in complete denial of for it defies everything they've ever known.
(as an aside, what was cool about the formal methods was that if you got the requirements right, and were able to derive the proofs, you essentially had a mathmatically correct pseudo-code and all that was needed as transcribing it into your favorite programming language. pretty freaky.)
I work at @stake (soon to be Symantec, if anybody stays). We commonly audit open code to test our automated auditing tool, and to prove teaching points in classes, and just to look cool publicly. We charge to do this for commercial companies, I have seen dozens of their commercial code bases and the quality is far lower than you would ever imagine. Want proof, run apispy and take a look at the strcpy frequency...no source required...source is for fixing, binaries are for breaking.
that is so retarded.
Maybe he's trying to pronounce it like Cartman.
"Hardly used" will not fetch you a better price for your brain.
You didn't see this in school? All of your assignments were flawless and on time? All of your programs did error checking of all user input? You spent half of the time on every assignment doing error testing with data sets generated to test every boundary condition? What about that History or Literature course that you couldn't care less about?
The idea of "good enough" or "I am sick and tired of this project" is not just found in the business world, it is basic human nature.
Networked computers depend on communication. Pretty any communication can be used to circumvent security. And there's all the people you can exploit, too. All you can you is make the lock as good as you can, but no lock will be perfect.
I'm still not convinced a structured approach to solving security problems is the most effective way to go about things. Microsoft has a very structured approach to dealing with security flaws and issues, but it takes forever to get a patch and there are still so many issues they seem oblivious to. Apache, on the other hand, seems to have a 0-day patch policy and does not benefit from a huge budget for testing and patching.
What I would argue is project morale is the single most important factor in dealing with security issues. If people are willing to take ownership of problems as they occur, the time it takes for problem resolution decreases (obviously). Within the constraints of a structured environment, there is bureaucracy to deal with, turn around time for tests and resource allocation, etc.
As a seasoned project manager, I can say these constraints are often the problem more so than the particular bug to be patched.
M
I'll suggest here that proper tools are an important way to prevent bugs and make auditing (reasoning about) software easier. And C is probably not a proper tool for creating secure software. Oh sure, if you're a super human coder and stick to a rigorously defined coding standard and have a team of other super human coders auditing the code with a fine tooth comb, you can produce C programs with fewer bugs than normal. But why not let the machines do the work for us? Try a language like O'Caml, or Haskell, you might like it! Besides having fewer lines of code to audit, you'll pretty much eliminate buffer overflows, fence post errors, interger overflows, etc.
The maintenance people prefer to use older but more stable versions to the point of living without nifty features for months until they are stable because alot (but by no means all) OSS software is regression tested on the users.
And that's the world that I come from. I've worked with IBM to get AIX patches created that pull bugs fixed on "current" versions back to older versions. I can't tell you how many times I've done it with database vendors - Oracle, Informix, etc. While these aren't fully vetted fixes, they've still gone through far more vigorous testing than doing the same thing with OSS - taking a specific patch and applying the code to an older version, for example.
You know what else? I'm happy to pay for those services. There's no way that I could know all of the ramifications of changing a few lines of code in the middle of a database engine without making that - knowing the database code - my full time job. And it isn't. Not that it might not be a fun way to spend my time, but hey, I've got other fun and profitable things to do with it instead.
For my personal stuff? Absolutely. Let me apply random patches. Update to new versions sight-unseen. If it doesn't work, I can roll back or just forge on ahead, figure it out, and send in new patches. Great. For my production environments, where downtime can be measured in thousands of dollars a minute? Not a chance in hell I take that risk.
You're special forces then? That's great! I just love your olympics!
When studying OSS security vs the security of proprietary software I think one of the most important differences between the two is the fact that OSS software is far more diverse then its proprietary counterpart. MS RPC can be found in all Windows-boxes for example while a Linux-box may use AFS, Sun's NFS, Samba or ProFTP to share files. Thus, when a security flaw is found in MS RPC a worm can quickly mitigate itself, infecting a large number of computers in a very short time. This is harder in the world of OSS due to its inherent diversity - a product of its development-technique.
We often compare computer-viruses/worms with its biological counterparts due the close similarity. Another parallel can be drawn between DNA and source-code. A population whose individuals have no or a very small genetic diversity is doomed due to their common faults (such as MS RPC). Think about the potato-famine in Ireland during the early 20th century where most of the potato-harvest was destroyed due to the practice of asexual potato-reproduction.
and exim and... whoops, that's three words.
The point of sendmail is that UNIX is open, so you can completely replace any component like sendmail if you want to. You can put out a UNIX distribution with a better mail server. People do.
Try to do the same thing with Exchange.
I maybe going out on a limb, but its hard to examine security without examining support. In my experience, OSS support is ahead by an order of magnitude, and perhaps it is by virtue if its nature.
:-)
For example, a vender of IP address space software (I won't say whom) had a problem with its software, and as a customer paying for both the software and the support, when I called in, I got the 'helpful' desk, got a ticket number, and then waited. I was also writing a python script, and a built-in method didn't seem to be returning the values I thought it should. I sent an email to the python developers list. In both cases, about the same amount of time and effort were spent verifying the problem. The next day, I got a response from python's auther. As for the commercial IP accress space management software, well, we switched to bind
This is my no means an isolated incident. The interesting difference is not the response time, but who got the information, and how many hands it passed through. In the OSS model, the info went straight to the developers, unmolested. In the closed software model, it got to the first level help desk, and possibly through a couple of other levels, and then maybe to a project manager, and then to a group leader, and then maybe it got to the actual developers. In the closed model, about 90% of the hands through which the info about a problem passes through don't even understand the issue at a fundamental level. No wonder we never heard back.
As I see it, the chief difference between the open source model and the closed source model is how many of the people directly involved in a project actually understand the project - and - does user input go directly to the developers.
So, I think its and issue of communication with developers. You would think the closed model would free up developers to just develop, but that doesn't seem to be the case. In the closed model, user input somethimes makes it to developers, in some form or another. In the open source model, uses grip directly to developers. Maybe that's why ethereal just installs and displays packets, and the commercial product I installed on my system captures packets, but you get an 800 number to help with viewing them.
Closed source seems to create a need for helpdesk people to take your calls, and open source seems to create a need to people to install and fix software.
But if we want people to learn about programming securely, we need Open Source, with all its visible foibles and its visible fixes. Otherwise, we'll end up with our college students studying the Microsoft agenda, and we all know how secure that codebase is.
As mentioned on /. just yesterday, here is just one person who has tracked down a lot of open source security issues: http://scary.beasts.org/security/. Regardless of how good he is at finding security bugs, the fact is that he found this many. How many more people like him are actively looking at open source?
Buffer overruns, arguably the most grievous security issue, are almost always the result of stupid programming and sometimes readily found by inspection. Consider the buffer overrun in Microsoft's bmp display code; the vulnerability was found within days of the Windows' source code leak and was found simply by inspection of the code. Given that the code had been around for a long time (the leaked code was originally part of NT 4.0, the leaked code came from win2K), what eyes at Microsoft were looking specifically for security issues?
Some buffer overflow cases not readily apparent to inspection of the code can be caught by automated source code checkers (google it, there are many papers on this) and Linux code has been subjected to exactly this kind of inspection (again, google). Windows code, not being open, may or may not have been subjected to this. How do you know? Given their abysmal record, I suspect it has not.
Given just these few facts, I think I do have to count security as one of the benefits of open source over closed source systems.
I was struck by something while reading this passage:
Not only is that sort of developer not looking for security bugs, but they're pretty likely to be just getting their feet wet working on that project and might well introduce a bug. Then, there's a significant possibility that nobody else cares about the feature that one developer added to scratch their own itch, so nobody's going to look at the code that implements it. Yes, there are more eyeballs, but those eyeballs are not evenly distributed. There are certain pieces of code that everybody is looking at, and there are vast tracts of code that practically nobody is looking at - none with an eye toward security. How many Linux drivers have you looked at? I'll bet the majority of the people reading this haven't really looked at any Linux kernel/driver code whatsoever. Have you looked at the code for Apache? Perl/Python/Ruby? MySQL? Gcc? Open-source users outnumber programmers a hundred to one, and each developer has a fairly narrow area that they're either interested in looking at or qualified to look at, so the number of eyeballs on some piece of code implementing an unpopular feature in a popular package is nowhere near what some people seem to think. It might be dozens, it might be one, and quite often it will be zero once the guy who wrote it moved on to something else. That's no better than the almost-always-one you'll get with commercial software, and sometimes it's worse.
Slashdot - News for Herds. Stuff that Splatters.
If the spelling in this artical is anything to judge by - "SecuritEy" is not spelt with an e in the end. then you got more problems with securiTY in open source than you realised. at least use a spell checker!!!!
I wish _I_was a multi-hundred thousandaire. ...Actually, 10,000 would be nice
...but it is completely not true for a project like OpenBSD. One of the last, true free and open projects.
The meme police, They live inside of my head
"Nah, this only works if you have a monopoly lock-in."
Maybe. But it is PRACTICED any time a company wants to beat a competitor to market OR to catch up to a competitor in that market.
"Sure, you're also kind of locked in if you just spent $20,000 on a software package you don't wanna throw away but that's full of bugs."
That's it. If you can sell it, it doesn't matter how buggy it is. That way you get MORE MONEY for "maintenance plans" and "support contracts" and "upgrade insurance".
"Still, this will destroy your reputation and do you no good in the end."
A bad rep and a product on the market will always beat a good rep and no product. There's this thing called "emotional investment" that happens a lot in this field. People get their own self-worth confused with the vendor or product and so they will stick with that vendor or product.
"The golden rule of business is to make your customers goals your own goals, because long-lasting relationships are essential to your own long-term success."
The other golden rules are that quarterly earnings matter and if your competition loses, you win.
is, BLANKET STATEMENTS. However, I'll admit that I'm a little pedantic.
The article does make some good points, but they're mired in the numerous blanket statements about the whole of OSS, and blanket statements only tend to draw the ire of those the writer wishes to reach. He tries to make up for that by saying "I would evaluate it only on a case-by-case basis," but that's not enough, IMHO.
// file: mice.h
#include "frickin_lasers.h"
So many of these articles that criticize FOSS from the corporate point of view are missing the real key which is that FOSS doesn't need them, it's quite the opposite. Adopting FOSS is like offshoring. It's not like China and India are pleading with all these multinational companies to come and set up shop and out of humanitarian brotherly love they decided to go. No, they're going there to save bucks --AKA the bottom line.
Same with open source. It's not like companies switch because they're doing a favor to open source. They have no position to criticize because they're coming begging. These are not friends looking to join in and contribute, these are simply corporate accounting offices saying cut costs --now damnit! They're using open source to save money and then we get twits like this guy whining about the deal.
For many home users, security is a non issue. Take me for instance. I have backups of all my documents and I don't care if people read them. The rest is just media and open source. Why do I care if somebody else sees these things? I got them for free, if somebody gets a copy it doesn't bother me a bit.
Sure, I don't want somebody to use up all my bandwidth sending spam, but that doesn't happen. That's about the extent to which I'm concerned about security and that's about the extent to which open source software takes care of my needs.
So, for a home user like me there is no security problem. As long as all my apps work and my net connection is smooth I'm good to go. I have no need for water tight security.
Now we get this corporate droid coming up with his theory that FOSS lacks security. Alright, then if that's the problem then his corporation shouldn't use it. He's absolutely right. Don't use it dude. It's too dangerous for you. You should have your company pay everything you can to MS or Sun. Meanwhile, his competitors who figure out how to make it work will have lower overhead and eventually whiners like this will be gone. It's a self healing problem.
We all know he's wrong. The evidence against closed source is so daming it's insane. I hear people talking about people booting up with a LiveCD. Well duh. If you have access to the console no system is safe. This is nothin' but FUD. The real question is who owes this guy and his type anything? Instead of whining, perhaps he should join a security project if he's so concerned. But he's not really concerned at all. He's just looking for attention.
I haven't read the article, but here's a question to ponder: When was the last time a virus ran rampant through your Linux servers? I know I had a hell of a time when my users would save a file, it'd be infected, and it's run through the network faster then Taco Bell through me. Now that we're on Linux, I don't have NEARLY the same issues that I did with Windows. My uptimes are in months, instead of days or weeks, my users have a stable environment, and best of all, it's free. So anyone can spread all the FUD they want, but the bottom line is that Linux has more then proven itself to be a world class OS that's immune to a lot of the problems that Windows suffers from. And best of all? I can feel my hair growing back in places where I previously ripped it out! :)
what you said had absolutely nothing to do with the article or the original proverb; you just wanted to let everone know about your bizarre political beliefs.
...it is surprising to me how much of this discussion revolves around programs which are monopolists or close to it. OSS programs have a large advantage - you may use solid toolkits, libraries and code developed by others and that has withstood real-life use from other projects.
Perhaps the code, open as closed started out with as many bugs. Now assume one is in a single CSS product, and the other is used in 4-5 OSS projects, each using it in different ways and testing its limits. Which is more likely to run into the bugs and fix it?
What if the CSS product is outcompeted on other grounds, like features. Then what? Then it doesn't matter how many bugs were ironed out, how secure the code is now. The work is for all intents and purposes lost.
There's no magic bullet to writing solid code - but at least in OSS, you shouldn't need to redo from scratch. Yes, I know I'm oversimplifying and that importing alien code is hard - but you could say that about OSS in general. Overall, it seems to work out quite well...
Kjella
Live today, because you never know what tomorrow brings
The reality is, the best marketed products generally make more money. Security has little to do with it.
You can't even read your own link? It had nothing to do with the kernel. It was in their NTP and BGP daemons, which both had the same bug because the NTP daemon was written by using large portions of the BGP daemons code.
No human indever is flawless, no manmade thing is perfect. As far as closed vs. open source the bigest difference is being able to work on something till you are satisified vs. working on it till someone wants to sell it. That said if the OSS developer is working for someone they may be under the same sort of pressure to release now, fix later.
And don't forget about the clients themselves. Patched to the gills, I thought we were ready for the world (no, not the band). Sure enough, today I counted 4 out of 12 computers already ahve some screwed up toolbar installed.
I can't blame the girls now. These guys have a financial incentive now to 'push install' this crap whether we want it or not. How's THAT for TCO? Does MS figure this sort of bullshit in?
Funny, I don't see any of this happening on the Macs here or my Linux box in the office...
"...Well, there's egg and bacon; egg sausage and bacon; egg and spam; egg bacon and spam; egg bacon sausage and spam..."
The article points out one of the problems in open source security auditing: there are simply no good auditing tools. Anyone who tried to use RATS or Flawfinder on a huge legacy codebase will know how frustrating it is to sift through tons of false alerts...
Du kan använda å på Slashdot numera.
The thing is that "open source" can mean many things. Probably the main reason that Linux (the flagship of open source) is secure is just because normal users don't have system control. This is something it inherited from Unix, but isn't specific to its code development process.
My distribution of Linux, Debian is stable because it is not a company, and it doesn't have to release new product too often to make marketting happy. Because there is no profit motive, Debian can take the time to release stable packages. If Debian was not using open source, this was still be the case.
So, it isn't specific to open source, but many open source projects have other features that make them more secure.
Hopefully I didn't put any [] around my words.
I find that many of these people cannot step out of the old corporate way of looking at things and see the big picture.
GJC
Gregory Casamento
## Chief Maintainer for GNUstep
Secure programming needs peer review. Peer review is not just releasing the software and let others read the code, if they feel like it. Do you go through the things you download off the 'Net? Do you search the Usenet for peer reviews before you start using software? Do you have any ideas wheither the software you use is secure or not?
The OpenBSD guys has the habit of regulary go through the codebase and clear out any doubious code. OpenBSD is not sexy, it is not even up-to-date in RFCs for basic services. That is the prize of being secure.
So, next time you feel the urge to write some nifty code to gain you fame and glory; do something good instead. Take some abandonned piece of critical OSS. Go through the code and find the bad habits. Don't look for holes, look for the general way of handling data.
If you manage, your are tidying the park rather littering.
:-) = I am happy
:^) = I am happy with my big nose
C:\> = I am happy with my OS
I guess to put things another way, for security, you don't put your faith, trust, and expectations in the software running on the computer, or in the computer itself.
Until we have sentient machines, to 'trust' them is to anthropomorphize them. Or like HAL, to distrust them, too.
The deserving target of faith, trust, and expectations are the *people* supplying the software and hardware, and administering the end result.
Perhaps that's one reason I tend to trust Open Source more, because usually I have at least some visibility into the *people* behind it. Though I've never met Linus, or any of the others in that ballpark, I've at least read their writings and seen their exchanges. I know at least a little about them, as people. That's hard to get with proprietary software.
The living have better things to do than to continue hating the dead.
With closed source software, the client must depend on the vendor's procedures for security compliance.
With open source, it's always possible to perform an audit yourself or hire some one to do so. You can decide what procedures to follow to do this.
If you expected software to be secure without verifying that systematic security tests had been done by someone, you may be in for a rude shock.
Duh.
"We reject as false the choice between our safety and our ideals." --The American President (20.1.2009)
still a myth.
you can't go and make a huge generalized statement like that and EVER find enough proof to back it up. it's like saying all apples are delicious...well yknow, some go rotten!! both the commercial and OSS camps have their solid secure apps, and their black sheep. OSS has the solid and legendary OpenBSD, M$ has windows win2k(which really aint bad altogether). OSS has the nasty and buggy sendmail, M$ has exchange server(yuck!!). The most secure apps are those that were designed with security in mind from the beginning, like vsftp, OpenBSD, etc...
sometimes, i wonder if i'm the only conservative on teh intarweb. ah well, back to mah hogs and warmongerin'....
The real benefits of opensource is a fast product delivery cycle if the people are motivated. That doesnt always mean that the security is a high priority. BUT there are open source projects that have security as a major concernt.
djbdns/qmail/the list goes on and on where the coders have a real insight into security and good code. In general the larger the project the more easily it is to overlook a security issue. Its always going to be that way and often its not intentional. Imagine having to remember 500,000 lines of code for all possible issues. Plus if you do audit your code there isnt always a garrnetee that your eyes will pick it up.
Flexibility and fast release times make opensource a very viable option. And most exploits are not remotely exploitable to servers (unlike many of Microsofts issues as one example)...
I use opensource for the majority of my personal work but I still believe that windows/microsoft is benefitcial to the industry as a whole. The exchange/sql/windows/iis solution is pretty robust and works very well if its configured well in a corporate environment. Put that onto the internet and its a different story.
If you look for them in a structured way, then you only find the ones that your structure is looking for ;)
The best that can be said for the security of Free Software products is that, by and large, it's way better than the norm in proprietary products. That's saying very little, though. There's enormous room for improvement throughout the entire population of coders.
The saving grace of Free Software is that it's personally embarrassing to have a security hole found in your code. Holes in proprietary products are generally not (publicly) traceable to the culprit. Even when they are, he can generally blame a manager. Not much of Free Software is written by people who don't give a damn.
i've always wanted to go to africa.
They do very thorough security audits on their software, ones which I think are more comprehensive than many comercial software products. Most software commercial and open source can be made secure if the network and computing environment are designed with security in mind. The truth is that if the people writing the software have the ability to patch it quickly and the companies had proper IT and data security people monitoring the systems the amount of break in would drop off.
This isn't even close to being true. Why are you spreading this misinformation? Serious security problems in large open source projects are very competitive with smaller projects in their bug fix and turn around. Nearly every majory security problem is fixed the day it hits the media. Most often when
There may be exceptions, but they are rare.
Sigs are awesome huh?
so what gives? the existence of a fix will not automatically deploy it onto all affected machines. Most bugs in Windows are long known, long "fixed", still you find hundreds of thousands of vulnerable machines out there.
if he can prove Microsoft is looking for security flaws in an "structured" way.
Pardon me while I laugh myself into a coma.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
In my experience a whole lot of redundant but singularly inadequate systems beats a single well designed system.
:)
Of course the ultimate would be redundant well designed systems, but we do have resource limitations, you know
Cheers.
...but he does not believe those eyeballs are looking for security problems in a structured way.
As a developer of proprietary software (hey, no flames, it's my job), I can assure you that there is very little structured security analysis of closed source software. Some closed software may be rigorously audited because of its nature, but the same holds true in Open Source (OpenBSD). You're not going to see any security audits for non-security software. You might see a few half-hearted attempts at it (like Microsoft's month long fix-fest), and very localized panic attacks when vulnerabilities are made public, but for the most part it's an ignored area of development.
"Security through obscurity" is still king, because the people making software security decisions in commercial firms generally don't know any other way. They also do not see the financial value in secure software, because it's not something that the customer will pay extra for in non-security related software. Then there's the problem of ignorant coders.
We have all gone through the phase where we think we know about security and encryption. In a proprietary environment such a security ignoramus can reach chief software architect level. In my own work I've seen three "clever" encryption schemes by senior developers that were complete jokes. One scheme even produced *sequential* keys it was so bad. In the Open Source community such security hubris is slapped down quickly.
In short, the author is wrong. Open Source is not inherently more secure than proprietary software, but the open development model encourages a higher level of security analysis.
Don't blame me, I didn't vote for either of them!
minute 1: friends interested in security
minute 2: Friends squirm uncomfortable
minute 4: friend is thinking "why wont he shut up?"
minute 6: friend is desperatly looking around room for help...everybody else went to look at something in the garage
minute 8: Laughing is heard from the garage..you think "I hate those people in the garage"
minute 10: eyes glass over as your friend welcomes the warm glow of self induced coma
minute 16: friend relized you FINALLY shut up 1 minute ago and is waiting for your to respond..or maybe breath.
Minute 17: in a panic your friend says "So, that will make windows secure"
Minute 20: your friend is trying to remember is it across not down, or down not across.
The Kruger Dunning explains most post on
The writer is saying that OSS developers dont have the right tools/expertise to check for security in their projects. So in essence, do we need an open source code quality managment system to be written for extensions for python, c, c++, assembler, etc? If that could be accomplished without a proprietary product, that would be the end all be all for code quality/security... b/c even the proprietary companies would use it (though not admittedly).
So come up with a CVS where the author's name is on the blocks of code he has written. And then other programmers that review that block of code can sign off on it, so thier names are also documented.
Then if there is a hole found the Author's work and the Reviewer's work in other areas of the program can be reviewed by others for possibly more holes.
There is the commonly held position that many F/OSS projects get source patches out the doro very quickly.
r -in-cvs to the time it takes for something tos how up on windows update.
That's true.
One problem with this is people compare the time-to-released-source-patch-on-a-mailing-list-o
I don't think that's fair for the following reasons:
1) Patch Quality.
It is clear that the volume of basic testing done on many instant-turn-around source patches is zero.
Comparatively, as often as an MS patch manages to break something somewhere, consider how much worse it would be if there weren't a few days of targeted regression testing being done. The official recommendation from MS is to test patches before putting them into production, but there have been a relatively low number of patch recalls from MS.
Finally, i think it bears mentioning that with F/OSS, the initial patch is sometimes re-written over the course of several days until something proper actually is agreed upon and that's the code that actually ends up living with the product.
So i'd consider these source level patches to very often be of "here is something that appears to close the hole and not break anything i tried, good luck!" quality.
2) Patch Applicability
When a hole is discovered in apache, the time it took for an apache developer to submit a source diff is NOT the same deliverable as what you're getting from a commercial vendor patch. A source level patch only does me any good if i am running a source-built tarball in production, and i am relatively current with whatever source base the patch is applied against, and i can handle the manual patch/compile/make install process (and if something goes wrong, i've got to backout the patch and compile/make install _again_)
Most people, especially running production machines, are not running built-from-source software. You install Redhat. You want apache ? You use the redhat apache package. You now need to wait for the updated redhat apache package to get the bugfix, or, you get the latest cvs snap and build from source. Now you've got a lovely problem because the way redhat (or any distro) builds apache is different from the defaults, so you have to go and figure out how your distro likes to build its packages, OR, you need to accept the build defaults and rebase your config files to the new settings.
So really, the vendor binary package is what many people need to wait for before they can truly patch thier machines. THe source diff is nice, but not something they can easily consume
I think between these two points, it's pretty unfair to compare time-to-patch between MS and someone-posted-a-diff-somewhere.
I think if you look at the time from vuln report to updated binary tarball being released by some of the linux distros, you'll be surprised.
My opinions are my own, and do not necessarily represent those of my employer.
There are some open source programs which are more popular than Microsoft offerings, like Apache. If Apache has more flaws than IIS, they seem to be much harder to discover by blackhats who would like to exploit them.
What matters is not that there is a flaw but whether or not it's discovered and someone does damage with it.
Some day, when everyone's using Apache 10, and Apache 2 is a thing of the past, someone discovering a vulnerability in Apache 2 that no one uses anymore is just wasting their time.
This is a practical issue. Show me the bugs. The fact that there might THEORETICALLY be more bugs doesn't affect anyone. What matters are those bugs which are FOUND and EXPLOITED.
What's more, being open source, Apache bugs should be easier for the blackhats to find. So if there are so many, why aren't they being exploited?
I think people have to forget about the cliche that all open source software is developed by some kid in his attic. A lot of OSS is developed using the same control process as commercial software, _but_ as an extra the source code is open. I can't see how in these cases it can be worse? Of course there are and always be OSS project made just for fun or out of an itch and perhaps in these cases the article could have a point (although i don't agree, as small project with little developers can take advantage of the 'many eyeball' idea, and people _do_ look).
On a long enough timeline, the survival rate for everyone drops to zero.
Seriously ... computer security is getting lots of windbags their 15 minutes. Resist it! All that matters is that holes are being fixed at an acceptable rate in Linux, Apache, Firefox, IE, Windows, etc.
But I'll sum it up in a few lines.
According to him, there may be "more eyeballs" looking at open source software
More eyes looking at something means more chances of finding problems, dumbass.
but he does not believe those eyeballs are looking for security problems in a structured way."
As compared to the fantastic job some structured companies have done?
BTW, you'll note that the worm authors do not have any sort of gigantic megacorporation providing them with "structure", but you'll notice that they seem to find security holes to exploit just fine.
To sum up: Viega is a moron.
Weaselmancer
rediculous.
The knees have jerked and posted. Both sides.
The truth is that software engineering is hard. Good software engineering is very hard. Good secure software engineering is really hard.
If the open source community wants to write good secure software, they'll have to work really hard.
Commercial software producers have a financial incentive to release insecure and buggy software.
The reason why Windows will never be thought of as anything more than a toy is because Microsoft itself doesn't see it in any other light. If it breaks, well, its your problem, not ours - sorry if you think otherwise; you should have read the EULA.
While MS serves as a shining example, they are not alone. You might think that the financial clout of commercial developers would ensure secure software, but you'd be wrong, at least as far as the desktop market is concerned. Once you break into the enterprise market, then you'll find a little bit better conditions.
It basically boils down to this: pride and money:
Given these motivating factors, it is unlikely that commercial software will ever be able to match the security and reliability of OS/Free software. Granted, a commercial app could be secure, but a company that actually spent the time to adequately debug security holes would have a difficult time pleasing the stockholders.
The society for a thought-free internet welcomes you.
Why is this guy trying to make ESR's quote, "Given enough eyeballs, all bugs are shallow." expand to mean that there won't be bugs?
:-)
The quote simply says: If there are a lot of people troubleshooting code, then all bugs are no big deal.
I don't know if that's provable, but it seems to be true. If you throw a whole team at fixing a bug in a proprietary program environment, then it seems intuitive that they'll understood a lot quicker than one guy working on the same problem. Why? Because when you hit the foo code, you can ask Fred, the foo expert. Then when the bug is in the bar code, you can ask Dave, the bar expert.
It doesn't say anything about there being no bugs or no security holes.
In fact, I'd say that if you wanted software that is security hole free, then the only program you can run are ones that you, yourself, audit at the assembly level.
Anyway, I think the redeeming security related quality of open source is that the end-users can have some influence on the software and things like security holes are fixed really quickly.
Ciao!
The Doctor What (KF6VNC)
Sendmail is crap.
(One of the lone examples for crappy OSS, btw)
We suffer more in our imagination than in reality. - Seneca
The open source community has done some cool, amazing things, but now needs to swallow a big humble pill (yes, just like the company you love to hate has had to do) and change their process to be more preventative, rather than focusing on patches so much (although patching is certainly not something to abandon).
Tee author of this article puts quite some weight on the fact that commercial software can be audited by the company who produces it, but we must no forget that:
1) These audits must be conducted by third parties, in order to be trusted;
2) These audits are not done for free, and are added to the cost of the software.
The cost of auditing open-source software will probably have to be passed to the customers, for smaller projects. It could be split among groups of interested customers and benefit the whole community, and still remain cheaper than most commercial alternatives.
Of course, big customers (the Navy?) could implement their own auditing scheme and pay for it, and commercial software companies would probably open their source code to these priviledged customers. Unfortunately most small companies cannot afford to call Microsoft, or Accpac, or SAP, and force them to provide their source code and get an audit from a specific auditor. (And, as we saw lately, relying only on the reputation of such auditing companies as the Big Four can mean that they will give good results to their big golf buddies...)
Finally, customers like the Navy would probably get cheaper software if they would go for F/OSS alternatives and audit them at their own cost, rather than pay for audited commercial software.
Re: your sig: I see an even worse one at our local supermarket:
"Warning: May contain traces of peanuts or peanut oil".
Where was this label found? On a glass jar...of peanuts. Keep in mind it was a see-through glass jar, making it obvious even to people who can't read, that it is a jar of freakin' peanuts.
My take on it: The warning was telling us that it might be a jar of fake peanut substitutes, by saying that the jar mearly MAY contain peanuts, instead of saying that it definately did.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
You're kidding, right? How to find crappy OSS: close your eyes and throw a dart at sourceforge.
-Tom Duff
I didn't RTFA, but can anyone convince me that this is the case with close source? Nope.
sells these days. Oddly he appears to blame everyone else for a bug he didn't spot himself for three years. Users suddenly didn't turn into code monkeys just because they used the software. And you can't turn them into beta-testers against their will. It's a potential, not a given.
The kind of methodology he wants for OSS just isn't going to happen across the board. Just as in commercial software, the "best practice" style you learned in college gets thrown out once you actually have to DO something.
Large projects require similar methodology just to keep consistent, but small programs will never do so. This is the real world, not the classroom!
insecurity asks the wrong question irritation gives the wrong answer
What you say looks like something insightful, but when I go and look for some examples I see it more like FUD. Take the latest gtk vulnerabilities.9 94916275&w=2)
Disclosed on bugtraq: 2004-09-15 (http://marc.theaimsgroup.com/?l=bugtraq&m=109528
New corrected packages from Red Hat: 2004-09-15 (http://rhn.redhat.com/errata/RHSA-2004-447.html)
New corrected packages from Debian: 2004-09-17 (http://www.debian.org/security/2004/dsa-549)
Looking at other security advisories show similar delays. Seems OK to me...
There was at least one person that wrote the software originally. Sure their might not be an ongoing audit however is there an audit on commerical software every year? So their were at least 2 eyes the one who wrote the driver and the one who accepted it to the kernel.
gcc -Wall giving a clean compile is becoming the default standard for FOSS. No-one is rigorously enforcing this standard however many projects are taking this on board and cleaning up their codebases. lint can be very tricky to set up especially cross checking lint (better than -Wall) so few people bother with it.