With So Many Eyeballs, Is Open Source Security Better? (esecurityplanet.com)

Sean Michael Kerner, writing for eSecurity Planet: Back in 1999, Eric Raymond coined the term "Linus' Law," which stipulates that given enough eyeballs, all bugs are shallow. Linus' Law, named in honor of Linux creator Linus Torvalds, has for nearly two decades been used by some as a doctrine to explain why open source software should have better security. In recent years, open source projects and code have experienced multiple security issues, but does that mean Linus' Law isn't valid?

According to Dirk Hohndel, VP and Chief Open Source Officer at VMware, Linus' Law still works, but there are larger software development issues that impact both open source as well as closed source code that are of equal or greater importance. "I think that in every development model, security is always a challenge," Hohndel said. Hohndel said developers are typically motivated by innovation and figuring out how to make something work, and security isn't always the priority that it should be. "I think security is not something we should think of as an open source versus closed source concept, but as an industry," Hohndel said.

Comments

Q: Who's auditing the code?

[Anonymous Coward]

A: Other people

More eyes

[Bengie]

More is better when it comes to bugs that are mostly obvious to the typical person, but doesn't benefit complex code that whooshes over the head of 99.9% of people. My co-workers tell me I have an attention to detail. Some code will get 3-5 people looking at it and testing it over a period of a month or two, then the'll ask me to take a look. Many times I will find several bugs in 10-15 minutes by just reading the code, then I'll have questions about the code and ask them to run some tests that will further find some more bugs.

I do not trust normal humans to anything technical right. I would prefer languages that work better with static analysis, more free tools to provide quality static analysis, and more fuzz testing.

Re:More eyes

[bluefoxlucid]

This is why some of us are insistent that the decades of experience which gave rise to design patterns actually means something. Folks often counter argue that good programmers "know what their code does" and so the mess of unstructured spaghetti code is fine "as long as it works"; they don't believe in engineering in containment of bugs and impact.

When you build your code to be a set of tools with defined behaviors and interfaces, you encapsulate bugs. An error in one piece of code creates a defect in the interface, which you correct in one place. This seems like something wholly-imaginary until you realize un-breaking a bug in many flat programs causes unexpected behavior due to other code relying on the defective logic's incorrect impact on some program state.

In an ideal world, none of this would matter. We do all this stuff because it matters in the real world.

Re:More eyes

[Let's All Be Chinese]

It's not that the patterns themselves have failed, just that their use has fizzled due to failure to live up to the claimed benefits of using them. I've never actually even read the book, but I took a gander at the "antipatterns" book (only thing in category available at the library at that time) and it immediately struck me as "middle management trying to program", or something in a similar vein.

Now, there's indubitably a lot of "code grinders" Out There for whom this sort of thing is actually a boon. The best and brightest among us tend to scoff at such people, or more specifically at their stumbling and crutches, with all sorts of plausible-sounding but not actually helpful counters like "good people know what their code does", conveniently forgetting that most programmers aren't very good at all. So perhaps "patterns" are a useful crutch to keeping a lid on the damage from the inevitable Dunning-Kruger effects in business programming. I don't know, maybe.

But it was only until very much later that I found this writeup and my take-away is that this sort of thing, I think including touting lists of "patterns" as fix-alls for programming trouble, are attempts at taking an inherently mapping mode thing into something suitable for packers to use. The better approach is to knock such people into mapping mode, but that's much harder to sustain. And could well count as cruel and unusual.

Visibility is always better than invisibility

[Bruce Perens]

When software doesn't have visible source code, the legitimate users have no assurances regarding what it's doing, other than those imposed by the operating system (which they might not have complete source for either).

However, the bad guys still take the trouble to disassemble the code and find its vulnerabilities.

With many eyes, you still might not find all bugs, but you can, and can do so without the unreasonable investment of disassembling the code and reading disassembly - which is not like reading the real source code.

The larger issue is that we need publicly-disclosed source code for some things, to assure the public good, whether it is proprietary or Open Source. For example the emission control code in automobiles, which it turns out multiple manufacturers have defrauded.

Re:Visibility is always better than invisibility

[hcs_$reboot]

I tend to agree. However, on the other hand, Open Source has "so many eyeballs" that most people trust it blindly, which can be dangerous.

Re:Visibility is always better than invisibility

[angel'o'sphere]

Very true, I only read open source source code if there is a bug I need to maneauver around or fix.
And most code is so bad, you don't really want to read it because of the night mares they induce, e.g. looking at https://lucene.apache.org/

Re: Visibility is always better than invisibility

[Bruce Perens]

While there is no guarantee that some eyes will not be malicious, I think your statement doesn't really fit the probabilities. Most people who look at code will be looking because they want to modify it, because they have questions that can be answered better by the source than by documentation, because they are looking for examples of how to do something, or because they are curious. Most of these people have good intentions and will even experience some emotional fulfillment from helping to eliminate a bug and thus help all of the other users. People like the public-benefit aspect of Open Source and want to help.

Re:Visibility is always better than invisibility

[Bruce Perens]

If you are thinking of bugs like Heartbleed, there are also economic issues. OpenSSL was issued under a gift-style license. Big companies that were making billions on desktop software used it, and almost never returned either work or money to the project. This one guy, Ben, had most of the load out of his personal time.

Now, this is not something the OpenSSL guys might ever have considered, and I am not representing them. But what if OpenSSL had been dual-licensed? All the Free Software folks would have had it for free, and all of the commercial folks would have had to pay a reasonable fee. In fact everybody would be paying something, either by making more great Free Software or by paying money. There might have been fewer commercial users, but there might also have been an income stream for Ben or other developers, and they might have been able to devote more time to finding bugs. So, there might never have been a Heartbleed.

Re:Visibility is always better than invisibility

[Bruce Perens]

We've mostly won this battle in the industry. You can't really not use Open Source in your IT department any longer. And IT managers who insist on avoiding it, rather than learn about it, don't get ahead.

Re:Visibility is always better than invisibility

[Bruce Perens]

you don't need the source code to verify vehicle emission output, this is why we test the vehicles

You're missing the fact that the code was made to game the test, and changed emission parameters when the vehicle was on a dynamometer, which is the way emissions tests are done. It was found by a little university lab doing an unrelated experiment, that happened to instrument the vehicle while it was in motion, and simply couldn't get their results to agree with the published emission figures.

Re:Visibility is always better than invisibility

[Bruce Perens]

It also prevents ridiculous incompetence like hard-coded passwords in production releases.

So true. Most people write better when the world is looking over their shoulder. I'd like to put a certain politician on C-span for all of his waking hours. It would work a lot better than simply reading the brain-farts he emits on twitter and in press conferences.

Re:Visibility is always better than invisibility

[Solandri]

Whether the eyeballs are paid is irrelevant. One of the interesting findings from the investigation of the Space Shuttle Challenger disaster was that NASA triple-checked components. But it turned out the three (paid) inspectors often assumed the other two were doing their job, and regularly skipped inspections on more-difficult-to-access parts. Since all three were biased to skip the same parts, those parts frequently went uninspected before launch. So in that particular case, having more eyeballs actually led to less security, than having a single inspector who knew the entire burden of security was resting on his/her shoulders.

People are lazy.

You have to be looking first

[sjbe]

Back in 1999, Eric Raymond coined the term "Linus' Law," which stipulates that given enough eyeballs, all bugs are shallow.

That's only true if those eyeballs are actually looking for bugs and organized enough to do something about them. Even then it's more like a principle than an actual truth. Some bugs are much harder to find than others no matter how many people are looking.

Re:Linus is right

[geschbacher79]

This is exactly right. It's not about open vs closed source, but eyeballs. For instance, take the HeartBleed / OpenSSL bugs from a few years ago. OpenSSL is used extremely often and all over the place, including by Google, Facebook, etc. But it had vulnerabilities in it that had existed for years and years, and it was because OpenSSL was really only being maintained by a handful of people.

But I think even more so, some organizations just aren't dedicating people to finding problems. You can still exploit Android, even though it's powered by Google and Linux. Intel has issues with its processor designs. Apple had a bug a year or so ago where anyone could log in as root. And these are the companies that supposedly have the best developers and essentially unlimited resources.

Exactly. Shallow, not non-existent. Personal examp

[raymorris]

Exactly. ESR summed up Linus's thoughts as ".. all bugs are shallow", not "all bugs don't exist".

Linus's exact words were:
"Somebody finds the problem, and somebody else *understands* it."

I'll share two examples from my own experience. Somebody found the shell shock bug and suggested a fix. Over the next few hours, hundreds of people looked at it. Some saw that the suggested fix wouldn't quite cover this variation or that variation, so they tweaked it. Florian Weimer, from Red Hat, said those tweaks would never cover all the variations, and suggested an entirely different fix, one that went to crux of the problem. Over the next few days, there was a lot of discussion. Eventually it became clear that Florian had been right. When he looked at the problem, he immediately understood it deeply. Well, it looked deep to us. To him, it was shallow.

""Somebody finds the problem, and somebody else *understands* it", Linus said. Stéphane Chazelas found shellshock, Florian understood it, fully, immediately.

There was no need to release a patch to fix the patch for the patch as we often see from Microsoft, or as we've seen from Intel lately. With hundreds of people looking at it, somebody saw the right solution, easily.

Here's another example from my personal experience with the Linux storage stack:
https://slashdot.org/comments....

Security vs Law Enforcement: 2 impossible missions

[holophrastic]

I have trouble with this industry-concept that software security should be put first -- it's an impossible business objective.

Think about how many industries focus on security. Banks, sure. Money transport, of course. Prisons and jails.

My air conditioner broke last week. It needed a new capacitor. It was a 5-minute $0 fix. Walk between the houses, open the compartment, pull out the breaker.

Now imagine your air conditioner, with the software industry's concept of security. Can you? How many check-points for a repairman to get to my air conditioner? How much added hardware? How much added expense in dollars and time? What stops someone from throwing a paint-filled balloon from fifty-feet away?

Security, when lives aren't at risk, is just so rarely worth it.

And when lives are at risk? Maybe you have a lock on your front door. Maybe it's a deadbolt. Maybe it's a really fancy locking mechanism, super-secure. Your front door is likely right next to a glass window. Congrats on the lock. Enjoy the bars on your windows.

And what stops your car, at highway speeds, from hitting another car at highway speeds? Right, a thin strip of white paint. Excellent. Sometimes the paint is yellow, even better.

We've never focused on security. We simply cannot afford to.

Instead, we talk about insurance, and criminal law enforcement.

So that's what I'm suggesting for software. Law enforcement. Deterrents.

Anything else, well, is just uncivilized.

Re:Linus is right

[swillden]

You can still exploit Android

Actually, it's pretty darned hard to do that on an up-to-date device (e.g. Pixel). There will always be vulnerabilities, but SELinux and other efforts have made Android a pretty hard target lately. Except, of course, for the fact that many device makers don't update.

And these are the companies that supposedly have the best developers and essentially unlimited resources.

Regarding Google, I think the developers are generally quite good, but resources are far from unlimited. I work on the Android platform security team, and we're always overstretched. That's partly because we set ambitious goals, but mostly because it's just really hard to find people. Part of that is location -- we currently only hire in Mountain View, Kirkland and London, so we can only hire people willing to live in one of those locations -- but most of it is because good software engineers who also know security are just hard to find.

Re:Exactly. Shallow, not non-existent. Personal ex

[Aighearach]

My experience was, I saw a bug report in some open source and tried to fix it, and by the time I had a patch written a better one was already released upstream and I was the last person to upgrade because I was off trying to write a patch.

There are so many freakin' eyeballs available, volunteers are mostly just jerks like me who are getting in the way trying to help! You have to have an inside line to the developers or security researchers to even learn about a bug early enough to have anybody notice even if you understood it as soon as you heard about it.

Even writing new types of network servers; somebody announced they were abandoning a web middleware tool that was popular, and so I started plugging away at an apache module, but within a week somebody else released something similar enough to mine that I just stopped coding and used theirs. Sure, my architecture choices were better, but theirs weren't bad enough to amount to bugs so nobody would ever notice or care.

Programming is easy, the hard part is finding an unserved use case! And fixing known bugs is a pretty obvious use case.

Start by posting your idea

[raymorris]

Your experiences remind me of something I learned about open source development. I now start by posting about what I intend to do. I've received these responses:

John is working on that and expects to release it next week.

No need to do all that, just use setting Xyx and skip the last part.

That seemed like a good idea, but when we looked into it we noticed this trap.

We decided we want Betaflight to focus on LOS. Your idea fits better with the iNav fork, which already does most of that.

Hey that's a good idea. Can you also allow multiples? That would be useful for me. I can help test.