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.
Securitey, it's like 'Security' but with an extra 'e' for effort!
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.
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
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.
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.
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.
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.
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
$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!
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.
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.
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.
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?
...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.