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."
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.
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.
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.
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.
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.
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'm part of a team that maintains a web service that, among other things, has a user-interface that generates a SQL query to generate a report over various database tables. Actually, it doesn't generate the SQL queries, they were all pregenerated and stored in a file. The final webpage contains several of these queries as options that you can then send back to the server through a query string parameter to a page that displays the results of the SQL query.
I was able to delete several database tables using this page, because it exposes the database table names and no checking is done on the SQL query.
This is not considered a big security concern, though, because the page works "good enough" for now. We're commited to fixing it "sometime in the future."
"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.
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.