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!
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 ?
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.
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!
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
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
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.
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
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!
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.
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.
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
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.
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 |
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
#
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!)
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.
$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.
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
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.
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.
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.
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.
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.
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.
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!
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.
"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.
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.
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'....
If you look for them in a structured way, then you only find the ones that your structure is looking for ;)
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?
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!
...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!
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.
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.
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.
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