Security — Open Vs. Closed

AlexGr points out an article in ACM Queue, "Open vs. Closed," in which Richard Ford prods at all the unknowns and grey areas in the question: is the open source or the closed source model more secure? While Ford notes that "there is no better way to start an argument among a group of developers than proclaiming Operating System A to be 'more secure' than Operating System B," he goes on to provide a nuanced and intelligent discussion on the subject, which includes guidelines as to where the use of "security through obscurity" may be appropriate.

What does slashdot think?

I wonder which side slashdot will take in this argument...

endless debate

Applications and systems developed that are developed rapidly by a small set of programmers would benifit from closed source security especially when producing software for small niches. Systems that are developed on a large scale and mission critial applications benefit from open source models because that can utilize a large tester base.

Vista Forum [vistahelpforum.com]

Re:endless debate

Systems that are developed on a large scale and mission critial applications benefit from open source m0dels because that can utilize a large tester base

I see it in terms of receiving what was paid for.

A program which costs $200 (typified as the industry and closed source) should not be relying on the consumer to be the (security) beta testers.

A program which costs nothing, or only a nominal amount (typified as FOSS), is able to ethically rely on the consumer base to be (security) beta testers.

If I paid for it then it should work (shouldn't break/shouldn't be so easily exploitable). If I didn't pay for it then I should expect to make a contribution.

Right now the industry is addicted to charging production quality prices for beta (even alpha) quality software.

His rule of thumb is useful.

Actually, his conclusion contains a far more useful test, although it does boil down to common sense:

The difference between these cases is simple: determinism. In the case of the encryption software, the outcome is deterministic. Knowing everything about the mechanism doesn't compromise the security of the outcome. In contrast, for antivirus software the system is heuristic. As such, some things benefit from disclosure, and some things don't. In these two cases, it's obvious. Unfortunately, that's the exception, not the rule. The problem is that many systems contain aspects that are heuristic and aspects that are deterministic.

In essence, the question is to ask whether closing the source really results in any increased security; in the case of DRM systems (his example), it does, because they are broken by default and thus knowledge of the 'algorithm' allows the system to be cracked.

Personally, I would argue that such 'heuristically secured' systems are broken by default, and that there are good reasons why generations of computer scientists have insisted that security through obscurity is meaningless. The "security" provided by such heuristics are of value only to marketing and legal departments, they are not and should not be confused with the security offered by 'deterministically secured' systems (e.g. cryptography is his example). Saying that an application is "secure," when it depends on an attacker not knowing how it works, borders on unethical false advertising.

closed source is just one aspect

Businesses that choose to develop closed-source software seem to also choose to ship code prematurely, to over-provision with extra features, to decide on features for marketing rather than security or quality reasons, and generally compromise the product in multiple ways. In that light, closed source isn't itself the security problem, it's just an indicator that there probably are other problems lurking.

Re:closed source is just one aspect

But those same companies are at the mercy of consumers, just like anybody else. If there is enough bad press due to the poor security of the product, the company will be forced to fix things. This is especially true for companies that sell software to large corporations.

Microsoft really is a case in point. They did a lot of what you described, got nailed for it by the press, by consumers, and by corporations, and they really did change their ways. Their Secure Development Lifecycle [microsoft.com] has turned out some pretty high quality releases. For instance, IIS 6 has far fewer vulnerabilities than Apache. One certainly couldn't say that for IIS 5.

Simple

The Operating System most secure is the Operating System less used.

Re:Simple

That was Intel's Realtime Multitasking eXecutive - a REAL TIME operating system. Security wasn't its job. You may as well ask how the security on QNX or a PLC is. Answer: nobody cares, as long as the I/O completes on time.

You Can't Know Which is More Secure

With regards to the question which product is more secure, the only right answer is that you will never know. The problem is that you can't eliminate bias from a test that is supposed to assess this. Since a single product can't be both open source and closed source, you will always be comparing multiple products. As stated earlier, you can't reliably establish the relative security of these products, let alone attribute the result to open vs. closed source.

Re:You Can't Know Which is More Secure

``This means there is no way to define a 'more secure' approach, and therefore all we can do is discuss individual products in comparison with one another.''

And I'm saying that even that is pretty meaningless. Five vulnerabilities were fixed in Mozilla last week, and two in Opera. Which is more secure? Twelve new vulnerabilities have been discovered in Firefox, and one in Opera. Which is more secure? The Apache servers in our sample have been broken into 50 times during the course of our study, compared to 3 break ins for lighttpd. Which is more secure? A team of five experts found three vulnerabilities in the NT kernel and two in Linux. Which is more secure? Static analysis found 10000 possible vulnerabilities in Konqueror and Microsoft reports static analysis found 1000 possible vulnerabilities in MSIE. Which is more secure? Which of the mentioned products should you select, based on the given facts, if your goal is to minimize future break ins?

I honestly don't know the answer to any of the questions I asked. I really think none of the (fictional) data I gave says anything about the relative security about the products it ostensibly pertains to. I _feel_ more secure running OpenBSD than Windows 2000, and, given the absense of reports of OpenBSD machines being broken into on a large scale, that feeling seems justified. But this is entirely based on something that I _don't_ know. I _don't_ know that OpenBSD machines are massively broken into, and thus, I feel safe. However, I also don't know that they are _not_ massively broken into, so my feeling could be entirely misplaced. I certainly don't know that there are no holes in OpenBSD, so even if it hasn't been massively exploited up to now, it could start tomorrow. All I have is the assurance of the developers that they make great efforts to improve security. I believe them, hope they are indeed doing so, and hope they are actually _achieving_ better security that way. But I don't _know_ that.

The Quantity of the Eyes Isn't Always The Issue

One supposed advantage of open source software is that, well, it's open. Everybody can take a look and see if the code has holes. The idea being that the more eyes that look at something, the greater a chance of somebody seeing bugs.

But the quantity of eyes isn't always the issue. I could put the Linux kernel source code in front of 1 million six year olds, and there is very little chance any of them would find a single bug.

Obviously, we're not talking about six year old eyes here, but continue the scenario. There are some types of bugs that even very experienced coders wouldn't necessarily spot. Not every kind of security hole is a simple buffer overflow. Some kinds of issues will really only be spotted by a highly trained and specialized set of eyes.

Now, those highly trained eyes may be looking at the open source code, or they may not. All I'm saying is that the quote "Given enough eyeballs, all bugs are shallow" is not particularly accurate.

Re:The Quantity of the Eyes Isn't Always The Issue

Now, those highly trained eyes may be looking at the open source code, or they may not. All I'm saying is that the quote "Given enough eyeballs, all bugs are shallow" is not particularly accurate.

I think, however, the "open source is more secure" argument tends to follow the idea that behind the scenes, the code under closed source applications tends to be generally faulty, or, at least, Windows code in particular. There could very well be many exploits that, given the code for MS Vista, amateur programmers could easily pick out, simply because the code base is so vast and the amount of people who have full access to it so few.

It's just like if I write my own little closed source app, at first it may appear to be flawless to me because I am the only one seeing the code. But I might code in an inherently buggy way that would be easily picked up by another set of eyes. Then, as little problems flood in from end users, instead of fixing my coding methodology, I make little fixes to the code that are basically workarounds around perhaps solving a bigger problem that would require more time (something more fundamental to the way the program is structured). As an effect, the "patches" become more and more around fixing faults than providing the functionality intended in the first place. Whereas with open source, someone might've already just forked my project and coded the idea using different data structures or in a largely more efficient way.

It's not to say that I couldn't be flawless, but, the odds decrease when nobody can see the results. Using closed source software is like running a car without access to the engine. You see things going wrong, but as far as why and how they are happening, if they are huge problems or only small ones, you can't determine without diving into the actual car's components directly. Closed source doesn't allow this. It's not just the fact that there are multiple eyes, then, it's the fact that those eyes are outside the original coder, potentially, sometimes even being the people having the problems themselves. It takes the "how do we recreate the bug?" discussion out, and oftentimes a sufficient end user can not only support his/herself, but improve the codebase.

Honestly, seems like a better approach. The hard thing is you can't know which is more secure really. But in practice, let's be honest, Linux and OSS get fixed more quickly if they are a widely used project in the OSS community than MS products and "patch tuesday" where they schedule patch releases and recommend strange workarounds for existing security breaches.

Well...

While Ford notes that "there is no better way to start an argument among a group of developers than proclaiming Operating System A to be 'more secure' than Operating System B,"

Unless of course Operating System A is Open BSD ;-)

does a password = security through obscurity?

FTFA - For example, passwords are the perfect example of "acceptable" security through obscurity: they are useful only if the attacker doesn't know them.

I would have thought that the password authentication method was the part that needed to be secured.

Just look at how many times an auth method has been exploited to bypass passwords entirely.

The Wrong Question

This debate is all about the incorrect question. The reason is that code can be secure or not secure, regardless of its "open" or "closed" status.

Until the industry realizes that "secure is secure" and stops worrying about the open or proprietary nature of things, this debate will probably prevent things from being as secure as they could be by diverting resources to an analysis rather than any solutions.

Put another way: Is a homemade door more or less secure than a professionally installed door? My answer is "it depends on the skills of those involved and the quality of materials".

The same applies to software.

Security by Obscurity

Is always a good first line of defense. At least it keeps out the riff-raff. Until someone smarter writes the scripts for them.

I have a pre-canned explanation of open vs closed

Closed security: the Titanic is unsinkable - White Star line
Open security: the Titanic's hull is made of brittle metal and thus isn't safe - Independent safety inspector

open how?

Open to the point of letting people know one's password?

I don't think that works.

Algorithm? May be.

It comes down to this, from bad guys .. it should be as "closed" as possible. From good guys, it should be as "open as possible". Because the good guys are likely to tell you flaws in the system, whereas bad guys aren't.

As a symptom of society in general to become more and more suspicious of each other, what is getting adopted is the worst of both the closed and open model is the one that persecutes security researchers (good guys) for finding vulnerabilities. Furthermore, it is fast becoming a crime to warn your friends that a particular software may be easily compromisable.

Reverse engineering must be legal. Warning people of vulnerabilities must be legal.

My Take

The same old argument for openness applies to open source. You have to assume the black hats will find and try to exploit vulnerabilities. Without that assumption, there isn't much to worry about. But given that the black hats will find vulnerabilities and use them, the best thing we can do is to make sure the white hats find the vulnerabilities, too. This way, the vulnerabilities can be fixed or worked around (e.g. through firewalls). The vulnerabilities exist whether or not you know about them, but, if you know about them, you can take adequate measures. Open source makes it easier to find vulnerabilities, and thus, to know about vulnerabilities.

Of course, open source also makes it easier for the black hats to find the vulnerabilities. So there's an arms race here. If the black hats find the vulnerability first, they can exploit it before it gets patched or worked around. If the white hats find it first, it can be fixed or worked around before it is exploited. The same arms race exists for closed source and open source, but, in the case of closed source software, the developers are (supposedly) the only ones with the source code, which gives them a slight edge in the arms race.

So it seems that both open source and closed source have advantages and disadvantages when it comes to security. Furthermore, I think that both arguments are theoretical, and the advantages that both models have are not always exploited. Having the source available does not help if no white hats are actually auditing it. And this is why open source wins, in my book. With open source, if you're concerned about vulnerabilities in the software and don't trust the rest of the world to have done proper audits and notified you about the results, you can do your own audit. If the developers of the software don't fix the vulnerabilities to your satisfaction, you can do so yourself. With closed source, you are at the mercy of the vendor. If they don't do proper audits, you're out of luck. If they don't fix vulnerabilities, you're out of luck.

Proprietary software vendors do not always have your best interests in mind. It's not unusual for vendors to keep silent about vulnerabilities found and/or fixed in their software, and some vendors have even threatened or sued people who have disclosed vulnerabilities in the vendor's software. The reputation is more important than the _actual_ security of the product, because the actual security is unknowable. With open source, such tacticts don't work. The source is out there, anyone can find the vulnerabilties and assess the security for themselves. If things are fixed, anyone can make a diff between the two versions and see what was fixed. They can't keep the information from you. Your security benefits from that.

You have to take out the weakest link

Which, regardless of operating system, is the interface unit located between the chair and keyboard. That interface can bring the most secure system to its knees.

security through obscurity just another layer

Okay, let's look at just one service, SSH. Without security through obscurity, you can do things like keep OpenSSH patched, use very good passwords, disallow root logins, restrict logins to certain users (which is kinda security through obscurity, but...)

And on servers I run like that, I have yet to have a breakin, but I do get up to thousands of connection attempts from ssh worms, from the same servers, every day (well, they would if I stopped dropping them in iptables, but nevermind that). So it's possible that they could hit a user with a bad password, or one they got from another compromised machine.

On other boxes, like my home box, I put SSH on a high-numbered port. In a couple of years I've had zero attempts hit that port. It would be quite stupid to rely only on this trick, ignoring good discipline in other areas. But as a supplementary layer, it's quite useful. If nothing else, it saves bandwidth.

It's not sufficient, but it's not inherently bad.

sploit!=patch

It's easy to find a buffer overflow by looking for strcpy calls with a debugger in a closed source program. It's a lot harder to fix them in a closed source program though, as you have no idea what to fix. The attacker doesn't need to understand the program to attack it, he just needs to understand a small part of it. The defender needs to understand all of it to patch it. Look at the CTSS bug involving a race condition and the system editor. The attacker just waited, and then he got the password file. Finding out what had happened was a lot harder.

My light fixtures are safe, really, trust me.

Say, I make these light fixtures. You can screw in a bulb but you cant see the insides, its design, how close the leads come togather, the quality of the materials used, the quality of workmanship etc. No independant certifying agency like Underwriter's Laborataries has seen it. No consumer advocacy group has tested it. But I state solemnly that "to the best of my knowledge and belief, it is safe". All my employees in the Quality Assurance Department, (whose job depends on my ability to sell this gizmo) state sincerely that this product is safe. This should be enough right?

Why is it that people are debating closed versus open software?

What is UNSECURE

If you have a large project that only the developers and the bad guys bother to examine closely, it's LESS secure than a similar project with many white-hat eyeballs on it and LESS secure than a similar project with only the developers looking at it.

This assumes the code has security-related bugs that are exploitable if found by the bad guys. It also assumes that the development team, despite their best efforts, doesn't find all the bugs that the bad guys could find if they had access to the source code.

Without the source code, the bad guys can find and exploit bugs, but their job is a lot harder.

Here's an example of how this might come into play in the real world:

I develop a set of cgi scripts to support e-Commerce. I publish them as open-source. They don't get very popular and I'm pretty much the only one using them. A well-known company uses the scripts and some black hats recognize my scripts. They study the source code, find an exploit, and harm the company that's using my scripts.

If the scripts were kept closed-source OR they'd become popular enough to have widespread community bug-squashing, the risk to the end-user would be much less.

Software Engineering is a young discipline?

The article concludes that "Software Engineering is a young discipline". The term was first coined in 1961, so I'd like to suggest that only recently have many agreed on what software engineering actually is, and how it should be undertaken.

Open security has to be more secure

If you can't prove it is secure by showing me how it works, then it's not secure. How do I know that there isn't some bolt in the back of the bank vault, or some skeleton key, unless you allow me to inspect it myself?

Security by faith or by fact, which would you prefer?

Who writes it? For whom?

If I can't see the code myself, I am forced to trust that the vendor has refrained from inserting a backdoor in the code. As for third party audits, I trust them as much as I would trust Microsoft to hire an impartial third party to determine whether a new Office version actually increases productivity.

I don't care how many pictures of keys, keyholes, locks, policemen, security guards, castles, gates or agents in glasses the website hawking the product has, how high it ranks on cnet, how many recommendations it gets by editorial staff in magazines, or how many times superlatives ("military grade", "256 bit", "tinfoil hat", "for the ultra-paranoid"), are used in conjunction with the word "security" in a review or the product description. IF I CAN'T SEE THE CODE, I DON'T TRUST THE APPLICATION. PERIOD.

The next level above that is code that I can see - typically open source. At least then it is theoretically possible that someone could get caught inserting a backdoor, with resulting impact on their reputation. Compiling it yourself should be more secure than using something compiled by someone else. One should also consider who is writing it, and who has provided funds to write it. Should I trust them?

Above that is open source code that someone I trust has audited or written.

And above all is code that I have personally written.

Obviously there are trade-offs to be made (usually the only software available to me for my budget is either commercial or open source), but that's how I do the ranking.

Maybe it's time to re-read the classic "Reflections on Trusting Trust". http://www.acm.org/classics/sep95/ [acm.org]

Security = obscurity

All security *is* obscurity.

Just as all humans are ultimately cellular organisms, or all substances are ultimately subatomic particles. Security is the art of keeping something hidden by requiring something else that is hidden to reveal it, and repeated applications of this principle in various distinguishable implementations.

The lock on a door is only as secure as the secret of where it's key is. Discover this secret, and act upon it, and the secret of the door is revealed.

Likewise, my encrypted email is only as secure as the secret of the contents of my secret key (which is only as secure as my login), and my passphrase.

Even a biometrically secured system is only as secure as the secret of where the user's body is and how to get it to the scanner.

I used to join in on the laughter of "security through obscurity". Then I realized how much of security really is just obscurity, and how it was often not much less practically effective than "real" security. Then I saw that this is because they are ultimately the same, merely in various complexities.

closed source graphs

The text labels on those graphs are illegible.

password are another kind of obscurity

for example, passwords are the perfect example of "acceptable" security through obscurity: they are useful only if the attacker doesn't know them.

The password is the data. The data can and should be remain closed. When we talk about security through obscurity we refer to the procedure, which is the executable code, the algorithm, what the hell the software does and how it does it.

I think that beeing dependent on the software vendor beats any advantage (if there are any) that closed-source may have.