Slashdot Mirror
How Does Heartbleed Alter the 'Open Source Is Safer' Discussion?
jammag writes: "Heartbleed has dealt a blow to the image of free and open source software. In the self-mythology of FOSS, bugs like Heartbleed aren't supposed to happen when the source code is freely available and being worked with daily. As Eric Raymond famously said, 'given enough eyeballs, all bugs are shallow.' Many users of proprietary software, tired of FOSS's continual claims of superior security, welcome the idea that Heartbleed has punctured FOSS's pretensions. But is that what has happened?"
Which is run by a former Microsoft executive who was in charge of security. I guess he can gloat about being personally responsible.
Help stamp out iliturcy.
In the self-mythology of FOSS, bugs like Heartbleed aren't supposed to happen when the source code is freely available and being worked with daily.
False. Bugs can and do happen. However, what can also happen with open source software is that entities other than the group working on the project can find bugs. In this case, Google found the bug. If the source were not open, maybe it would have never been officially recognized and fixed.
That's fine with me.
Yes, we can trace the changelogs in the software & note who was checking the changes and missed them, but that all can be circumvented.
The fact is we don't know if Heartbleed was an honest mistake or not...we don't know who knew and when...we don't know alot
FOSS is nowhere in the conversation, btw...this has absolutely nothing to do with the fact that this was Open Source project.
Private company's products have ridiculous security issues...comparing this to that is not helpful.
Thank you Dave Raggett
We're surrounded by tiny errors in the world. Heck, they're even built into our DNA. The vast majority of tiny little errors do no harm, and we don't notice them. We gloss over them, like a typo in a book. It's just that every once in a while, a tiny little error can occur that snowballs into something much greater. Like cancer. Or a massive, accidental security leak.
More eyeballs usually do make bugs more shallow, but only if the eyes know what to look for.
Occasionally living proof of the Ballmer peak.
Nobody is going to discard OpenSSL due to this - the majority of people are patching systems and reminding people that security is important (a side benefit of this incident)
The next step will be when someone puts up the money for a proper code review of the OpenSSL codebase and fixes up any other issues that may exist.
It's reasonable to say that there are more people and organisations able to resolve this issue than if it were a closed source proprietary solution.
Many eyeballs may make bugs shallower, but those many eyeballs don't really exist. Source availability does not translate to many people examining that source. People, myself included, may like to build to install packages but that's it.
What we need are intelligent bots to constantly trawl source repositories looking for bugs. People just don't have the time any more.
I don't think anyone claims that open-source software won't ever have security issues. The claim is that the open-source model tends to find and correct the flaws more effectively than the closed-source model, and that the soundness of the resulting product tends to be better on average.
One case does not disprove that. The key words there are "tends" and "on average".
How do we know that serious security flaws don't exist in the SSL implementations used by Microsoft or other proprietary vendors?
It's 6 of one, half-dozen of the other.
Anyone can view the source of an open source project, which means anyone can find vulnerabilities in it. Specifically, hackers wishing to exploit the software, as well as users withing to audit and fix the software. But, someone who knows what they're doing has to actually look at the source for that to matter; and this rarely happens.
Hackers must black-box closed source software to find exploits, which make it more difficult than finding them in open source software; the flip-side is that they can only by fixed by the few people who have the source. If the hacker doesn't disclose the exploit and the people with access to the code don't look for it, it goes unpatched forever.
Open source software does provide an advantage to both sides, hackers can find exploits more easily and users can fix them more easily; with closed source, you're at the mercy of the vendor to fix their code but, at the same time, it's more difficult for a hacker to find a vulnerability without access to the source.
Then, we consider how good fuzzing techniques have gotten and... well, as it becomes easier to find vulnerabilities in closed source software, open source starts to look better.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
So, the "with many eyes all bugs are shallow" notion fails. There were not enough eyes on the OpenSSL library, which is why nobody discovered the bug.
Except that someone did discover the bug, when they were looking at the code because it was open source. And they did report it. And it did get fixed. Later than anyone would want of course. But it happened. Maybe the similar errors would and are being missed in the Windows and Mac implementations.
Q: How Does Heartbleed Alter the 'Open Source Is Safer' Discussion?
A: It doesn't. OSS is purported to be a *better* software development methodology. "Better" != "perfect". TFS is a troll.
Il n'y a pas de Planet B.
What hasn't been found in closed source software because it is too inconvenient to look?
I don't know, Microsoft got caught about being able to waltz through the password check with full spaces, which is slightly worse than forgetting to place a character limit back onto something. Admittedly the stakes are not the same, but you can check it, and enough do that it works.
It's safer in terms of checking for back doors, sloppy coding anyone can do.
If the bug was in some proprietary SSL stack, would we even have heard about it? Would it have even been fixed? Who knows. That's the WHOLE POINT...
Show me on the 1st Amendment bobblehead where the moderator touched you...
This doesn't really change it, because think how a proprietary SSL library would've handled this. The vulnerability was found specifically because the source code was available and someone other than the owners went looking for problems. When was the last time you saw the source code for a piece of proprietary software available for anyone to look at? If it's available at all, it's under strict license terms that would've prevented anyone finding this vulnerability from saying anything to anyone about it. And the vendor, not wanting the PR problem that admitting to a problem would cause, would do exactly what they've done with so many other vulnerabilities in the past: sit on it and do nothing about it, to avoid giving anyone a hint that there's a problem. We'd still have been vulnerable, but we wouldn't know about it and wouldn't know we needed to do something to protect ourselves. Is that really more secure?
And if proprietary software is written so well that such vulnerabilities aren't as common, then why is it that the largest number of vulnerabilities are reported in proprietary software? And that despite more people being able to look for vulnerabilities in open-source software. In fact, being a professional software developer and knowing people working in the field, I'm fairly sure the average piece of proprietary software is of worse quality than the average open-source project. It's the inevitable effect of hiring the lowest-cost developers you can find combined with treating the fixing of bugs as a cost and prioritizing adding new features over fixing problems that nobody's complained about yet. And with nobody outside the company ever seeing the code, you're not going to be embarrassed or mocked for just how absolutely horrid that code is. The Daily WTF is based on reality, remember, and from personal experience I can tell you they aren't exaggerating. If anything, like Dilbert they're toning it down until it's semi-believable.
Comment removed based on user account deletion
Most of the non-OpenSSL instances of TLS implementations out there are probably SChannel.
I would be shocked if Microsoft hadn't had equally severe bugs, and further surprised if they could fix them as fast.
Comment removed based on user account deletion
What if this was not 'OpenSSL' but instead it was some form of 'ClosedSSL' library that had this problem in it?
NSA would still have access to THAT code, you can bet your ass they would, they wouldn't leave a project like that alone. However nobody else would know (unless stumbling upon it by chance or being able to access the source OR if some insider SOLD that information to somebody on the outside and now you'd have a vulnerability that is exploited by the gov't and by shadiest of the organisations/people out there).
This does not change the discussion in terms of open source code being safer, this changes the discussion around certain practices of development / testing and also this may attract more attention of people towards the SECURITY of our information on the Internet and hopefully we'll move in the direction of working out the details of actually much more SECURE methods of communications.
I certainly have a few ideas of my own that I would like to implement now, but never mind that. The point is that this is good stuff, it finally shed a light on this topic, that should have had much more light on it for a much longer period of time in the first place.
We need better methods around building security within our systems and I think this raises the bar.
You can't handle the truth.
Closed source was always safer.
One word for you: Microsoft. Maybe two: Adobe.
Closed source is not inherently safer. Raymond's proposition is theoretically sound, however in actual practice, the NSA has "many eyes"...
"Flyin' in just a sweet place,
Never been known to fail..."
Only if one buys that "security through obscurity" is a legitimate form of network safety. A decade's worth of Internet Explorer and ActiveX vulnerabilities would suggest you're wrong.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Closed source is hazardous in many ways. Along with being more frequently targeted, the NSA revelations showed that Microsoft worked with the NSA when deciding how quickly to close some holes. Another hazard is the threat of being attacked and/or sued by companies whose products were found to have problems.
No question the heartbleed thing is a huge and embarassing problem. But you know? It's actually kind of hard to count the number of high-profile vulnerabilities in F/OSS software as not a whole lot come to mind. On the other hand, the list is enormous for closed source from large companies... also hard to count but for another reason.
It does highlight one important thing about F/OSS, though. Just because a project has enjoyed a long, stable and wide deployment, code auditing and other security practices are pretty important and just because it's a very mature project doesn't mean something hasn't been there a long time and had simply gone unnoticed for a long, long time. People need wakeup calls from time to time and F/OSS developers can be among the worst when it comes to their attitudes about their territories and kingdoms. (I can't ever pass up the opportunity to complain about GIMP and GNOME... jackasses, the lot of them.)
The problem was found because the code was Open Source. If it had been closed source, then the bug would still be secret. To the extent to which the bug was recognized (or commissioned) and exploited by the likes of the NSA, it would have probably remained secret for a lot longer.
According to Microsoft's EULA, for example, finding -- much less fixing -- such a bug is illegal. If the NSA had paid them to put such a bug into the Windows version of SSL, then it would probably remain unpatched for years after someone had pointed it out to them as an exploitable bug.,, and anybody openly reporting such a bug, even after 6 months of trying to get MS to fix it, would be roundly criticized for disclosing the bug 'prematurely'.
Even then, it would probably not be fixed by Microsoft until at least the next monthly bug release cycle (or even the one after that.
With the code being Open Source, the problem got fixed faster than yesterday. Period. If the OpenSSL people refused to fix it, then it would have been forked. ... and more to the point: Such a security-centric fork would have been legal.
OS Software is like love: The best way to make it grow is to give it away.
I do believe open source is safer as it does absolutely allow for independant party review, which is how this bug was found. Because outside parties had access to OpenSSL they were able to find the problem, whereas with closed source software it might have never been found, or found but hushed up by the company. Proprietary software has just as many bugs as open source, if not more, the difference is there is less accountability.
That being said, the full potential of open source software in independant party review is not brought to its full potential but the fact that a lot of open source software is poorly documented as to the internal construction of the code. This ends up wasting time for programmers to basically have to spend more time than it should to learn the internals, and even wastes time of those running the project basically repeating explanations of the code whereas if they were to make some documentation people could get many more answers without having to bother the project leads. It makes the learning curve much steeper that when dealing with software that has a lot of code, to not have any documentation on how that code fits together. On one hand, we say that open source allows people to review the code, but just opening the source alone does not make it easy as possible for this to happen, the code needs internals documentation or else it often will take simply too much time for people on the outside for people to penetrate it. Many open source software projects end up with a cliche who understands the internals of the software because they wrote it, but its difficult for those on the outside to penetrate. Even for an expert programmer, being able to access documentation speeds up the time to become familiar with the code immensely.
Not doing code documentation is a poor practice and open source developers should document what they are doing for others and as well to save time by preventing having to explain things over and over again to newcomers.
PlUU-lease! Where is my "overrated" mods when I need them?
The NSA is why my hair has fallen out and my gut has gotten big. They're also behind the big mudslide in Washington. In fact, they are the boogeyman for EVERYTHING!
God you people get annoying.
It's BECAUSE of open source we even learned about Heartbleed. If it was closed source the hole would still exist hidden in the shadows.
The dangers of knowledge trigger emotional distress in human beings.
" just about every SSL-encrypted internet communication over the last two years has been compromised."
No, it really hasn't.
It's accurate to say that just about every Open-SSL encrypted session for servers that were using NEW versions of OpenSSL (not all those ones out there still stuck on 0.9.8(whatever) that never had the bug) were potentially vulnerable to attack.
That's bad, but it's a universe away from "every SSL session is compromized!!!" because that's not really true.
They were vulnerable to attack, that is to say, the security was compromised. He didn't say they were hacked, stolen, eavesdropped, or surreptitiously recorded.
compromise: to expose or make vulnerable to danger, suspicion, scandal, etc.; jeopardize: a military oversight that compromised the nation's defenses.
I've noticed that a lot of TV sci-fi confuses "compromise" with "breach"; as in hull, shields, defenses, etc.
my, your, his/her/its, our, your, their
I'm, you're, he's/she's/it's, we're, you're, they're
It's a statement. It's a statement by a dogmatist on one side, and there will be statements by dogmatists on the other side. Two dogmatists don't have discussions--they just try to shout one another down.
Yeah, if you get enough eyeballs on a problem, sure it might be easier to solve. But users != eyeballs. I suppose being open source, it is easier to get eyeballs on something, but it is also easier for the black hats to get eyeballs on something as well and exploit it.
In the end, neither side in the dogmatic divide is likely to listen let alone switch sides.
1. Proprietary software could have a million bugs like this. You just wouldn't know it. They do not become less dangerous because they are proprietary, nor do security flaws become more dangerous because they are in open-source code.
2. Open-source software at least has the possibility of being looked at over and over. Proprietary code may be reviewed or not depending on the resources, interest, and monetization capability of that code. A possible review by all relevant coders in the world is always more review than by a limited team of programmers and analysts at one company.
3. The real problem with Heartbleed is the time that passed between code being written and a bug being discovered. That delay exacerbates the security problem. However, there will be some sort of statistical (probably Poissonian or normal) distribution of the time required to catch a bug since introduction into code. As with anything, there are outliers. Heartbleed with its serious and longstanding flaw must be considered an outlier unless shown otherwise. I have not seen evidence that this happens on a regular basis with any software, FOSS or otherwise.
I would appreciate it if future Slashdot discussions were let out through the upper orifice with some maturation period in the brain, rather than through the lower orifice after festering in the colon.
Entia non sunt multiplicanda praeter necessitatem.
It has done so by making the issue public and allowing it to be given proper consideration, as opposed to being covered up by those in the know while people continue exploiting it. This is a significant step forward in the open source discussion because this is open source working as it should, the bug was found because there were many eyes in the general area. Open Source versus Closed Source is becoming the difference between systems you can vouch for and systems you can't.
In a closed source world we would have everybody vulnerable without anyone knowing about it. That only helps if you're one of the people abusing it, because nobody is taking precautions against it. Now we are actually able to respond to a real threat that we can explore deeply. Sorry, closed source is not going to give me confidence.
Raymond's proposition is theoretically sound
No, it isn't. It's nonsense and it always has been.
There is plenty of evidence for the effectiveness of good code reviews, but most of it shows rapidly diminishing returns with the number of reviewers. You get much of the benefit from having even one or two additional people read over something. By the time you've had more than four or five people take a look, the difference in effectiveness from adding more barely even registers, unless one of the additional reviewers has some sort of unique perspective or expertise that makes them not like the others.
Given that almost every major FOSS system software project has had its share of security bugs, there is really very little evidence to support Raymond's claim at all. It's not like it has ever been taken seriously outside the FOSS fan club, but there are a lot of FOSS fans on Slashdot, and so plenty of comments (and positive moderations) reinforce the groupthink as though it's some inherent truth.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
After a lot of soul searching whether or not I should actually honor this obvious attempt at trolling with a comment, I think I should, lest someone actually take it serious and believe it.
Allow me to take you on an excursion into the world of security. Before you get your hopes up, it's not as glamorous or kinda-sorta-shady-sinister-blackhat as you might think. But I'll try to make it as interesting as it can be.
Part of security are audits. Audits are, in a nutshell, attempts to find out whether there are weaknesses in the surface you're auditing. For example, you prod at a server, check its ports, make sure that everything that answers does so in a way that cannot be exploited, and so on.
Those that at least dabbled in security will know about the various "boxes" used to describe the "rules of engagement" in such an audit. Most commonly known, I'd guess, are "black" and "white" box tests. In a "black box" test, you get no or very little information about your target and your task is to find out whatever you can find about it. A "white box" test is the exact opposite, where you get full disclosure of your target's makeup, e.g. what services are running, at what patch level, often even what purpose they serve and what department they belong to, and so on.
One might now think that the more "normal", more "useful" test is a black box test. Because, hey, if I tell you everything, what the hell would you test? But, know what? A black box tests is something that you'd do to test the tester's ability, not that of your target. With a black box test you can rather find out just how much the guy you hired to do your audit actually knows about the whole shit.
If you actually want to test the target, you disclose about any information there is. That might sound odd now, but when you think about it, it starts to make a lot of sense. This information can be available to a potential attacker. A disgruntled ex-employee could have that information. Or someone who spends a lot of time social engineering and prodding can gain it somehow. Assuming that you could increase your security by withholding information from a potential attacker is at best giving you a false sense of security because you can NEVER actually say with at least a semblance of certainty that a potential attacker CAN NOT have that information. Like I said before, all it takes is a pissed off ex admin and this attacker would have ALL the information.
And it's rather trivial to sell information these days...
Now, what does this have to do with the question open vs. closed source?
It means that just because YOU do not have the information does not mean that your attacker does not have it. Closed source is akin to the black box in the aforementioned example, open source the white box. When you audit closed source, you will learn more about the abilities of your auditor rather than about the security level of the software you audit.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
2003 called, they want your Microsoft back.
If only we could.
We need a "+1 -- nice sig" moderation.
I think the grandparent was right. MS now is hugely better than the MS of 10-15 years ago. I'm not going to try and objectively prove that as I don't care enough about MS and probably couldn't anyway.
But the NT4 to XP/2003 era was appalling security wise - but they changed that. IIS went from swiss cheese to one of the tougher web servers to break. You just don't hear any more about the kinds of problems they used to have. If you endured those days or just laughed from the sidelines, you don't need any hard data to see that they have improved a lot.
I found this paper from Theo de Raadt illuminating though. He steps through 10+ years of OS hardening techniques OpenBSD has put in place to prevent badly written applications misbehaving. Towards the end he summarises how other platforms do this stuff - the only other platform that did it all by default was Windows (yikes!).
Closed source was always safer.
One word for you: Microsoft. Maybe two: Adobe.
THIS! It's funny how Microsoft has all the issues that they do, and yet when a problem shows up in anything else, the fanbois instantly ejaculate LOOK!! SEE???
Sorry kids, Windows has a many year legacy of needing constant security updates, way too many for you to be braying about this, as proof of the bankruptcy of FOSS.We get it, But Redmond products have a lead that will never be equaled.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
Open Source vs Closed Source is as much a philosophy as it is substance. We can argue the benefits of having many eyes on the code from Open Source as opposed to having funded coders with Closed Source. In the balance, each project will be different based upon its own unique factors. The one constant is that Open Source does have superior transparency.
How can you be a good chess player if you do not lose the odd game? So the opensource code got a strike against it, I am sure GNU/Opensource teams are coming back at this with a vengeance, developing better protection methods. Stuff like this will rally security teams. Sure, not all bugs/vulnerabilities can be caught, but the ones that are...will have the living s--t kicked out of it. Chalk it up to valuable experience. I am sure developers are whipping themsleves into a mea culpa frenzy. A bit of humility will go a long way to making something superior.
"SO we bide our time, waiting for a purer kick to bloom and the future is still bleak, uncertain and beautiful" -GSYBE
I think this says more about the prevailing view of security. Every programmer is told "NEVER roll your own encryption". The default result is that most programmers never even look at the code and instead assume it MUST be safe since the infallible "experts" wrote it. What we are seeing here is not the fault of open source vs closed source; it is about voodoo programming being considered good security practice.
I'm not saying that everyone should be rolling their own encryption, but people should be looking over the experts implementations instead of assuming they are perfect (this bug could have been caught by any number of "normal" programmers had they simply taken the time to looked).
Encryption is not security through obscurity. Encryption is security through rigorous openness and review.
"Security through obscurity is generally a pejorative term referring to a principle in security engineering, which attempts to use secrecy of design or implementation to provide security." The secret key in cryptography is neither design nor implementation.
Encryption is meant to make the original text be obscure, however the means of encryption should not remain obscure. What "security through obscurity" refers to is the common and naive practice of assuming that no one will guess your security methods, and the problem is that people do find this stuff out. Ie, assuming that no one will guess your backdoor debugger password. Now it is fine to start with a strong set of security practices and then only after that is in place it can be made more obscure. But usually when something is made obscure it is because the security is really weak in the first place.
As for ActiveX, the problem was not that the end user would go and hunt down a trusted plug in and install it, but that it relied upon the web to tell you if something was trusted and then automatically install it (and for the average user this happened even without their knowledge). This was done at the same time that Java was promoted as an alternative, a system that was intended to be designed for security by sandboxing the code (though of course it had flaws) as well as being cross platform, whereas ActiveX was all about taking plain x86 code and executing it as long as it was signed.
The real problem with ActiveX was the idiotic idea from Microsoft that it should be installed automatically without bothering the users with annoying questions such as asking for permission first; they did the same boneheaded move by allowing executables in emails to be executed without a confirmation. It wasn't until they started added UAC that it seemed they understood what the problem was.
I think that it's really not about open or closed source. It's about monoculture, the whole net is more resilient if we didn't do that. So many warned about that issue with the desktop/laptop running Windows, and that risk is there and real still, but while worrying about that we built it anyway in an a non-OS specific way on servers too
Safer != Perfect
Open Source is not perfect. It also does not help when you have large commercial institutions RELYING on the source code in a security critical role under constant attack by well-funded adversaries, AND the developers of said open source code are so pitifully underfunded, AND the commercial proprietors that cause said open source library to become a high-value target are only willing to invest in features, and not improvements that would lead to better quality and lesser likelihood of serious bugs.
Fixed within, 24 hours on 187 servers running open source openssl libraries, f and earlier versions.
I still do not have fixes for about 5 proprietary customer products, and there has been no word from 3 of them if they intend to fix them.
I have informed my customers that they should consider moving from the proprietary products IF they have the cash to do so.
I really do not see your point in asking the question.
You cannot design and build secure software to begin with.
You need to have the source code for the forseeable future now because of the world we live in.
Very very bad people are coming out of the pit and they want your infrastructure, your data and your intellectual property.
But above all, they want control of you.
Open Source can prevent a world like that from taking hold, but it cannot save a fool from his foolishness.
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
The quote is "given enough eyeballs, all bugs are shallow." That's a clear admission that open software, like all other software, contains bugs; that's why you want the many eyeballs. Any claim otherwise is a symptom of not understanding plain English. Eric's whole point was that the bugs in open software will be found and fixed faster than the bugs in other software, due to the population of interested people who will study it, looking for the bugs.
Perhaps it is not being stated clearly but the point that you are missing is the fact that this bug in some of the most critical network software in use had been around for 2 years. This fact demonstrates the hyperbole of the quote. Its a well crafted quote, illustrates a concept well, but people read way too much into it. Few FOSS users are developers, few developers are qualified readers. Eyeballs are a plus, but not a panacea. The gap between proprietary and open exists but it is exaggerated.
A second and more important fact is that the bug was not discovered by eyeballs on source code. The techniques used seem to be the same applied to proprietary closed source code.
"“We developed a product called Safeguard, which automatically tests things like encryption and authentication,” Chartier said. “We started testing the product on our own infrastructure, which uses Open SSL. And that’s how we found the bug.”"
http://readwrite.com/2014/04/1...
Nothing in that quote implies (to anyone with reasonable understanding of English and basic logic) that open software doesn't have bugs.
Straw man.
The visibility doesn't make it so bugs don't exist. It makes them more likely to be found. This one existed and was found.
After two years in the wild. And apparently *not* by eyeballs on source code. Proprietary or open seems irrelevant to this discovery.
"“We developed a product called Safeguard, which automatically tests things like encryption and authentication,” Chartier said. “We started testing the product on our own infrastructure, which uses Open SSL. And that’s how we found the bug.”"
http://readwrite.com/2014/04/1...