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."
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...
Well yes, that's partially because most of the time OSS "vendors" forego the testing procedures that commercial vendors do.
"It works on my box...bug must be fixed!"
This strategy doesn't hold water in the business world.
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
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.
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
That's true for small home-projects, but not for projects like Mozilla, Gnome, OpenOffice.org, Gimp, etc.
... and I'd rather have a WELL-TESTED commercial patch that doesn't break existing dependencies than a QUICK-HACK from the OSS community.
Speed is not the primary factor in patching software.
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
The problem is that if you ever want to go mainstream, you'll have to get your software out to the people who don't have a clue.
(You can walk my grandma through downloading a gzipped tarball.)
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.
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
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.
Do you have data supporting that claim? I've seen an independent study that patches for MS security flaws actually come faster than patches for Linux security flaws (though that could be in part because MS has more practice doing so as they have many more security flaws). And don't claim that study was really just financed by MS because their eventual conclusion was that the infrequency of Linux security flaws made up for the longer response time.
Mathematics is made of 50 percent formulas, 50 percent proofs, and 50 percent imagination.
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!)
Are you sure that's a fair comparison? Sendmail is a kludge. It's had bugfixes tacked onto features, tacked onto bugfixes, all heaped into a 25-year-old codebase. It's never been rewritten from the ground up, and by today's standards, it was a mess 25 years ago (when it was written, security was barely a blip on the radar screen). The same can be said for a package like WuFTPd.
What about a package like Qmail, or an OS like OpenBSD (let's leave opinions about DeRadtt and DJB out)? These are OSS packages, have a similar lifespan, and (AFAIK) they absolutely crush W2K's security track record.
I do, however, agree with you that the article has some merit. OSS doesn't necessarily guarantee security. After all, it's not neessarily the process, it's the people who make the product.
-Turkey
The Mozilla and other teams can be anal retentive when it comes to what code they allow. And anal retentivism is, in programming, a good thing.
You are not alone. This is not normal. None of this is normal.
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.
You know it's funny that you say that. I was in a software project management class my senior year in college. We were required to create a piece of software that did specific functions and turn it in at the end of the semester. Becuase this was a group project, all groups ended up missing some deadlines here or there, which inevitably cost them man hours in the long run (we were required to keep track fo cost). After about the 3rd missed deadline by groups (due to bug workouts, people not doing their part, etc.), my professory, a former IBM employee, told us a story.
He said one year, he was heading up a project that involved writing software for IBM machines. They were nearing the release date and still had dozens (if not more) of bugs to work out. He went to his boss, a B-school guy, and said "look, I know we're close to the deadline, but there are still many bugs that we really need to work out before this thing ships. We don't want to release a product that costs this much and still has some things wrong with him".
Now keep in mind that there were hundreds, if not thousands of companies ready to buy the machines as soon as it was released. They had orders from companies around the world. Because they were competing with other companies selling similar products, the need to meet the deadline was even more important.
Back to the story, his boss looked at him and said "so you mean to tell me that you think we should delay the release of a product that has the potential, and is almost guaranteed, to earn us hundreds of millions of dollars for a few bugs? I don't think so. We'll release the product and support it later on. Tech support will cost us less in the long run than delays at this point".
So they released the product, sent developer level techs around the world after companies began to complain about the bugs, and that was that.
Moral of the story? Sometimes, from a busines stand point, you should release the product and support its bugs later on. But that usually depends on the amount of competition in the market and money that is riding on the product. Yeah it sucks from a developers stand point, but developers dont make business decisions in the real world.
See Examples. HL2, DNF, etc.
Actually, Microsoft was founded in 1975. That would make them almost 30 years old.
As far as sendmail goes, that's why I don't use it. I use procmail for all my SMTP needs. Win2k is a great product, I was really happy when I was using it, but the bottom line is that it still has its problems. There are still patches that get released to address security issues every now and then.
All software has it's problems because it's written by people and people are imperfect. However, there are a lot of choices in the OSS world, just as there are in the closed source world. If you find a program doesn't work as advertised...move one. When it's open source software and I do move on, however, I'm just generally glad that I haven't had to invest several thousand dollars in the purchasing of the software.
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?
bah.. it's the fact that in the unix world, a program is written to do one thing and do it well. A fix in Firefox isn't going to break the KDE help, where a bug fix in IE could break Windows Help. A fix for bind isn't going to greak LDAP, but a fix for MSDNS could break Active Directory.
Intigration has lead to much longer testing times for a patch, because that patch can break so much more then what it's fixing. Gnome and KDE do suffer from this to an extent, but not as bad as some of the other players in the desktop game.
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 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.
Emphasis on *usually*. And if you weren't aware, almost all manpages are entirely out of date. *Years* out of date, even. Could you even imagine trying to maintain the bash man page? That's an entire job itself.
There is horrid source code out there, with no commenting or documentation. Most people point to Linux or Apache or some such for examples of where OSS succeeds, yet avoid looking at all the countless other OSS that has far fewer eyeballs looking over the source code.
It just does not work generalizing OSS as better than proprietary when it comes to quality or security matters.
Dijkstra Considered Dead
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.
I'd almost agree with checking the return values of sprintf(), but with a buffer overflow you'll be lucky if you returned where you thought you would anyway. And after all, that's why they made snprintf().
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!
"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.
I'm working for IBM at the moment and I can see this scenario... if this manager was a 2nd line manager he could have swayed his 1st line manager, given for a product there aren't many second line managers, it wouldn't take much for him to hold a lot of sway.
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'....
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.
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!
Nearly every majory security problem is fixed the day it hits the media.
There are two ways to achieve that: control the media, or fix bugs quickly. 8-)
Someone who discovers a bug in free software usually delays disclosure until the fix is ready. This creates the illusion of quick fixes, despite it usually takes two weeks or more to create a fix. (It's quite instructive to look at the time stamps contained in patches released by GNU/Linux distributors.)
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.
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