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.
All this episode does is to remind us that security is hard. Encryption is even harder.
Kriston
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.
The issue is not that some open source software has a bug in it. We're all grown-up enough (I hope) to realise that NO software is ever perfect.
The only interesting point about this situation is how the Open Source world reacts to it and what processes get put in place to reduce the risk of a similar situation arising in the future.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
Bugs happen, leaving the source open just gives individuals an opportunity to find them. It doesn't imply that all bugs will be found instantaneously, just that anyone can look for the bugs. Compare this to closed source, which has a very narrow group of people examining the code base, and only their word that everything is sound. I hate to think how long, if ever, a flaw like this would go unchecked and exploited if only the gatekeepers where allowed to check out the goods.
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.
The huge problem with OSS is that if no one takes the responsibility to do a good code audit for a project, the NSA will do that independently, file the found exploits, and tell nobody.
similar issue in closed source would have less chance of discovery, and if/when discovered would not be disclosed in the same way, but most like attempted to be kept on the dl.. while being exploited by interested parties.
At least with FOSS, you can quickly identify and fix problems that show up. Proprietary software fixes only happen when they have no other choice but to fix it.
I go out of my way to complicate the simple things, so that I can simplify the complicated things.
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
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
"Given enough eyeballs, all bugs are shallow" has proven true time and again. The key point in the phrase is "enough eyeballs". In this particular case, the affected software was OpenSSL. Let's examine that for a second.
OpenSSL is a cryptography library. Cryptography is, by definition, a very "exclusive" field of development due to the complex mathematics and rigorous rules that have to be followed in order to successfully contribute. It then follows that the audience that is both capable and willing to contribute to the project is very, very small in relation to the audiences readily available to other projects such as Apache Tomcat or GNOME.
This is where the "enough eyeballs" comes into play: clearly, for the longest time, there weren't enough. The reason is understandable and explained in the above paragraph - the vast majority of software developers out there are probably not able to contribute meaningfully to a project such as OpenSSL.
However, and echoing on other comments that have already been posted, the good news is that because it was open source the vulnerability was detected and corrected. Had it been closed-source it might never have been found - let alone acknowledged or even fixed. I'll take that over a walled garden any day of the week and twice on Sunday. That - to me, at least - reinforces the argument that open-source is safer and more secure than closed-source, not the other way around as some would like to believe. This is by the simple fact that larger number of eyeballs can be brought to bear on a piece of software in order to eventually shallow out the bugs.
How many closed-source companies are willing to make that level of investment in their software quality if they can still be profitable without having to do it? Further still, what if making that investment would bring profitability into question? Would they still make the investment? I think not...
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.
How?
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.
bugs are not the issue. it's how systems get updated once the bugs are fixed. without automatic security updates, heartbleed will be with us for a long long time.
So there was a bug in OpenSSL. Big bug, yes, but that's not the reason it was (and still is!) a big problem.
The genesis of the big problem is one of monoculture, not only of OpenSSL being the dominant SSL implementation, but probably more importantly, the fact that pretty much all Internet security that is accessible and matters to ordinary users is SSL/TLS in the first place.
If you think this is bad, imagine what happens if the fundamantals of SSL itself are compromised: What would we replace it with? How, considering this is effectively the only secure connection technology available across all common OSes and embedded devices? How long would that take? (Years, at least, I'd wager...)
What we need is more flexible security methods in the first place, and open, standard implementations (like OpenSSL, but growable) that can allow us to proactively extend security methods as the net matures, and *quickly* address bug-based vulnerabilities when that approach fails. (Note that this may require the implementation of some kind of standard "secuirity code VM", so new code and new methods can be easily distributed even to older systems that may not be fully supported anymore. And no, I'm not glossing over things like limits on code space, memory, and the like, nothing will allow every system to be upgraded, but we do need some way to allow and authenticate that (while preventing bad guys, including governments, from using the mechanism to create weaknesses.))
"The future's good and the present is nothing to sneeze at." - Roblimo's last
This alters the "Open source is safer" discussion in the same way that someone dying from an allergic reaction to a vaccine would alter the "Getting vaccinated is safer" discussion.
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.
How 'bout that SSL bug discovered not recently in OSX/iOS?
Sure the open source is not a silver bullet, nobody argues this.
And law of big numbers sure does it thing, yes, shit happens in open source just as well.
But how often this happens in open source vs closed source?
How often such incidents go unnoticed in closed source world?
Linux forever
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.
If I'm a malicious hacker, or the NSA, but I repeat myself....
I'd be now (if i wasn't before) checking the feeds for gnutls, nss,, and openssl, hoping to catch he bug before anyone else, so i can exploit it.
That said, I'd also be checking out the best decompilers to see if that helps me find bugs in closed source code. Im sure people have looked online for Windows source code to see if there are any ways to exploit it. In this case, a small group of hackers would have the code, and would necessarily want to limit the number of people aware of those exploits.
In a nutshell, we're all screwed.
One word for you: Microsoft.
2003 called, they want your Microsoft back. The Microsoft of 2014 has a better security record than almost every other vendor in the consumer field.
I would worry more about Flash, Java, Firefox and Android.
" 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
Data point: the NSA reportedly discovered this bug within days of its placement, and didn't disclose it.
When the bad guys have a lot more eyes than the good guys, it skews the math.
I've read the FOSS argument for years and I guess I have leaned in favor of it from a bug perspective. But in this case, I think closed source would have won, at least to the current point in time. If OpenSSL is truly behind 60-75% of the world's web servers, then the value in hacking it is enormous. Thus if I am a criminal organization, it might be worth spending $1M for guys to read that open source code and find problems that I can then monetize for a big profit.
I don't think you are going to get $1M worth of code inspection on the white hat side for OpenSSL. Maybe going forward it will, and companies may be willing to invest in the upkeep. Not out of goodness, but because it makes good business sense. For a large organization, how many soft and hard dollars have been chewed up in the last week doing analysis, patching, client communication and general PR for Heartbleed? Probably enough that a $10K donation in time or money to OpenSSL upkeep would be feasible.
There is also evidence that the bad guys have been exploiting this in the wild. So the usual argument of "we found the bug quicker with open source" is probably wrong here. The better-funded and more highly motivated bad guys found it quickest.
My guess is the bad guys have been working this bug against Yahoo for awhile. Yahoo told me a couple of months ago (and others I know) that someone was attempting to login to my account from Russia. I would now suspect Heartbleed here.
The logic for finding bugs on the black hat side is OR (find any bug and exploit). The logic on the white hat side is AND (prevent all bugs). The table is always tilted like this unfortunately in the security arena. Bugs will always happen and the good guys can't win every time, regardless of code access.
"Ever since the "Heartbleed" flaw in encryption protocol OpenSSL was made public on April 7 in the US there have been various questions about who knew what and when."
.. His private-sector experience includes serving as Vice President, Chief Information Security Officer and Chief Security Strategist at eBay and as Chief Security Officer for Microsoft ."
Company | Codenomicon: "Howard A. Schmidt, Chairman of the Board
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.
I would take my chances with FOSS. How crazy is the statement that XP can not be safely used without Microsoft support, given that they had 13 years to fix bugs in a feature-frozen release? In an open source release used for so long and on the same scale, chances of finding a new catastrophic bug would be slim. For example, Heartbleed was found in 3 years. Likewise goto fail bug in Apple open source was discovered in a relatively short time.
Not to mention that if new bugs were found in desupported but still somewhat popular open source software, users would create their own fix in no time rather than having to pay millions to Microsoft.
Heartbleed is a perfect example of why software should be written in "safe" languages, which can protect against buffer overruns, rather than unsafe languages like C and C++.
Of course, the problem is that if you try to distribute open source software written in a safe language, everyone bitches and whines about how they don't have a compiler for that language, and how run time checking slows the software down by 10%. Personally I'd rather have more reliable software that ran 10% slower, than less reliable software that ran faster. It's also crazy to turn off the run-time checks "after the software is debugged", as if the debugging process ever succeeded in finding all the bugs. As C.A.R. Hoare famously observed in 1973, "What would we think of a sailing enthusiast who wears his lifejacket when training on dry land, but takes it off as soon as he goes to sea?"
The "with enough eyes" argument, and "if programmers were just more careful" arguments don't justify continued widespread use of unsafe languages. Granted, safe languages don't eliminate all bugs, but they eliminate or negate the exploit value of huge classes of bugs that are not just theoretical, but are being exploited all the time.
I keep hoping that after enough vulnerabilities based on buffer overruns, bad pointer arithmetic, etc. are reported, and cost people real money, that things will change, but if Heartbleed doesn't make a good enough case for that, I despair of it ever happening.
Without the ability for anyone, not just a limited subset of employees, to access and modify the source code, the bug may have never been found. At best, it would have been found later and taken longer to fix.
That OpenSSL is open source is irrelevant. This bug could just as easily have happened in closed source software. Using closed source software does not give any higher confidence in the quality of the code; many studies (e.g., 2012 Coverity Scan Open Source Report) show generally comparable code quality, with some open source projects scoring substantially better than average.
You forget that this just happened to Apple a couple months ago in their SSL implementation. The misplaced goto statement caused them to ignore all certificate chain checking. Apple was quite fast in notifying people and working on a fix for it.
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.
I've heard other people say this too, but I don't see how that can be. Are there any stats that convincingly prove this? It seems to me that proprietary companies have some advantages when it comes to marketing. They can always sue people who claim they have found an exploit in the software. And there is no law obligating a proprietary company to announce when someone has found an exploit in their proprietary software and informed the company about it. So I would take claims that Microsoft has a "better" security record with a mountain of salt. Who is Microsoft being compared to? SCO? What is the metric? Where is the data?
But security and safety are not free, as peoples around the world are already familiar with. Free software in itself, as in the past few days has been laid out to dry by every VC-backed non-open idea factory in the US, is not the reason why you now need to change your passwords. The reasons should be self-evident.
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.
There are no reliable metrics that indicate FOSS is safer. None. FOSS is an ideology to many and that means that it is beyond reproach. The hailstorm of excuses that surrounded the fiasco of the Gnome/KDE 3 rollout is a case in point.
A big company that you hate does this and we have to hear about it for the next 20 years. FOSS does it and "oh it's open source so it's kinda OK, you know?"
Get off the smug position you hold and enter the real world. Heartbleed costs the FOSS world reputational damage and the best you can do is "maybe it would have never been officially recognized"?? So how then, do the bugs get recognized and patches developed for MS Patch Tuesday? Do angels whisper into the ears of MS executives?
I don't expect any of this to make an impact on you though. As I said going in, it's ideology you hold.
ESR's statement remains true.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
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.
In general maybe. This issue had nothing to do with encryption though (or hard security stuff even).
It was a very basic input checking error in a massively crusty overly obfuscated and badly written/documented codebase that all kinds of people have been tacking 'kitchen sink' style features onto for years. It's almost as if the codebase is actively trying to counteract the 'many eyes' effect.
OpenBSD has already taken on their fork and started stripping out cruft - who knows that fork could end up having a portable version that everyone else starts using (like with OpenSSH).
Companies like Google and RedHat etc are presumably going to be putting some extra resources into OpenSSL to help clean it up. It's importance means they would be crazy not to. Hopefully they also put some resources into funding/helping the OpenBSD fork too as a better longer term option.
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.
Microsoft Windows.
if this is supposed to be a new economy, how come they still want my old fashioned money?
All heart-bleed proves is that C+ is a poor language to be programming security software in.
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).
Hahaha, this is hilarious that the GP is +5 insightful.
Mod me down, my New Earth Global Warmingist friends!
it's not a matter of open source but a matter of having israel partisans working on mission critical code.
You're obviously a troll and an idiot, but just for the record: I don't know if Seggelmann is Jewish - his last name is, but then so are a lot of German last names... and he's German (not Israeli) and there aren't many German Jews left - but the reviewer of the code was Stephen Henson, who is not Jewish. Do you blame him too? RSA (the company that became synonymous with public crypto, and the algorithms they patented) stands for Ron Rivest, Adi Shamir, and Len Adleman. The last two are also Jews, and Adi Shamir is actually an Israeli. Do you blame them too? In fact, according to the Bible, there's this guy named Jesus who was also a Jew. Do you blame him too? As it happens, there are a disproportionate number of Israeli programmers in the tech space, mostly because as far as I can tell they've always had a high ratio of well-educated people in math and comp sci, and lately an influx of of well-educated former-Russians too. Thank god it wasn't an Indian or Chinese programmer who caused this, or /. servers would collapse from the comments.
Comment removed based on user account deletion
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.
Comment removed based on user account deletion
Comment removed based on user account deletion
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
Ahh a rare specimen of a mentally ill person on /.
The vulnerability was found specifically because the source code was available and someone other than the owners went looking for problems.
I keep seeing people claim this. Codenomicon didn't discover the bug by looking at the source, but I can't find any information about how Neel Mehta discovered the bug.
People will pass up steak once a week, for crap every day.
The bug was found by code review, twice independently in a short period of days.
Codenomicon didn't discover the bug due to a code review (source). I can't find any information on how Neel Mehta discovered the bug, though.
People will pass up steak once a week, for crap every day.
It's all a matter if spin. It should be "bug found and patched because of open source" if it was closed few if any would have been able to look and find and patch the bug
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.
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).
The irony is that the openssl authors chose to roll their own malloc implementation instead of using the default, trusted one which would have likely crashed instead of facilitating the leakage of memory. (I still blame the fundamentally flawed nature of C for even allowing this)
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...
I am of the opinion, and have been for a while, that casual coding (i.e. coding something in your free time, not backed by hint of monetary gain) is at the heart of the problem. People code casually because it is fun to do. They don't like writing comments, documentation, or clean code. This is not to mention that these project need good people that can write this complex code and putting massive amounts of rules and coding practices is not going to attract people to code in their free time. When you have code that is backed by money and/or a company, the motivation exists to do the not fun stuff, but the required stuff to make code more secure, more easy to audit, and easier to understand. Without that type of backing, you have people hacking away writing code as quick and dirty as possible. That is the reputation that FOSS is trying to get rid of. That is the reputation that hurts its adoption rate, especially in critical and important systems. That is the reputation that the OpenSSL vulnerability drags kicking and screaming into the limelight. Unfortunately, it is a reputation that has a significant basis in reality and, in my opinion, the Heartbleed vulnerability will have lasting effects for years to come.
Closed source just has deliberate NSA backdoors. Clearl superior and much more efficient than accidental backdoors.
"I is in your PC reading all your emailz!" - lolcat works for NSA
I am anarch of all I survey.
(150 + posts today alone, I hear)
For those of you playing along with us at home, it's up 212 messages this morning. Looks like 5-10 of those are from non-AC replies to my posts. Pretty sure at least 90% of the remainder are from APK.
Il n'y a pas de Planet B.
no, Raymond said the bugs are shallow, not non-existent - i'm sure you can understand the difference....
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
You DO realise that I can't post and moderate in the same discussion, don't you? In any case...
APK, I absolutely do not now, and I am not *ever* going to be convinced you've ever worked anywhere except maybe Burger King.
However, I AM convinced that you are a lying, bullying, spamming, crapflooding troll.
You make increasingly grandiose and decreasingly believable claims about yourself. Whenever you're questioned about these, your lies get even bigger. When you're called out on them, you start attacking people.
When you make idiotic claims about programming, and get called out on those... That's right, you start attacking people.
You also apparently think that linking to any old thing proves your lies and mischaracterisations. Like when you linked to a joke you plainly didn't understand, claiming it was proof that I have MPD. Or when you linked to ANOTHER joke of mine that you ALSO plainly did not "get", and claimed this was "proof" that I'm not a writer.
When your attempts at intimidation and mischaracterisation don't work, you just start repeating them... well, MINDLESSLY... in an attempt to turn up the volume and drown out dissenting voices.
You have been doing this again and again and again and again for over a decade. It's all over the WWW. I'm not even going to bother to link to anything, because anyone with one good finger and half a clue can type "Alexander Peter Kowalski" into Google and read for themselves all about your little escapades.
Il n'y a pas de Planet B.
Let's put it this way: If APK writes that the sky is blue, I'm going to look out my window and check it for myself before believing him.
Il n'y a pas de Planet B.
will you just fuck off polluting the posts with this shit
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
To really understand a lot of projects to the point where a developer can make substantial contributions often takes a substantial investment of time by a developer. So some combination of full-time employment in the area, government grants, a basic income, or gifts of some sort are required for experienced developers to have substantial time to look at source code. It's true some developers have time to do it as a hobby, and others might have time as students. But to really dig into complex code and keep at it for a substantial period of time require, in US society at least, generally requires some kind of external support (even if just a spouse who earns money). This issue is not helped by the fragmentation of many software projects via forks, the competition between similar FOSS projects, and the proliferation of languages and not-very-good standards which all chew up vast amounts of developer time.
Of course, some people, like Bill Gates, who was born with a substantial trust fund have inherited the wealth needed to allow them to develop free software the rest of their life. However, for good or bad, he did not pursue that choice.
"How to Become As Rich As Bill Gates"
http://philip.greenspun.com/bg...
"William Henry Gates III made his best decision on October 28, 1955, the night he was born. He chose J.W. Maxwell as his great-grandfather. Maxwell founded Seattle's National City Bank in 1906. His son, James Willard Maxwell was also a banker and established a million-dollar trust fund for William (Bill) Henry Gates III. In some of the later lessons, you will be encouraged to take entrepreneurial risks. You may find it comforting to remember that at any time you can fall back on a trust fund worth many millions of 1998 dollars."
A substantial "basic income" equivalent to US Social Security from birth would, in a sense, make everyone a millionaire overnight and give them the time they need to pursue public benefit projects, whether doing code review or raising children well. Linux in part is a result of Finland's generous support for students like Linus.
http://www.linfo.org/linus.htm...
"Torvalds thus decided to create a new operating system from scratch that was based on both MINIX and UNIX. It is unlikely that he was fully aware of the tremendous amount of work that would be necessary, and it is even far less likely that he could have envisioned the effects that his decision would have both on his life and on the rest of the world. Because university education in Finland is free and there was little pressure to graduate within four years, Torvalds decided to take a break and devote his full attention to his project."
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
It's just a question of how many of them that are discovered and how serious they are.
In this case it was a simple mistake, and had serious effects. In other cases the bugs may be caused not by simple mistakes but a very complex chain of mistakes and still just result in a small side-effect.
As I see it - the best way to avoid simple mistakes like missing to set a character limit is to restrict use of languages where this check isn't built into the language itself. C and C++ is good for some coding, but that code has to be strictly reviewed and cross-checked to ensure that it's secure. Other languages has a lower risk of simple mistakes because they don't allow the user to address data outside the boundaries of a declared variable, or they do extend the allocation of a variable when needed.
So looking into languages like Ada, Java, C# and Matlab/Simulink (or the clone Scilab) should be on the list of languages to consider. Even Basic would be worth to consider. Or if you want to be a bit more esoteric Erlang is not a bad choice.
Just be aware that almost every programming language has a basic platform written in C, so it's important to make sure that the platform doesn't have any problems.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Bye
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
In all this hoopla i havent bothered to look at the code in question yet, but im always slightly dismayed when i throw some popular open source stacks at commonly available but expensive static analysis tools like Coverity or Klocwork.
There are plenty of companies running full open source stack servers with the licenses available - i wonder how often things like OpenSSL and other critical infrastructure pieces go through the best static analysis tools available ? And how much of it gets addressed.
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
You do realize that encryption is security through obscurity ... right?
i don't think this quote means what you think it does.
Please don't quote shit that you utterly fail to understand.
ditto.
ActiveX is just a plugin system,
as much as a shotgun against your head is just a metal tube.
the ignorance runs deep here.
don't be so modest. you just contributed a fair share.
Your demonstrated chronic inability to appreciate any kind of humour whatsoever has absolutely no bearing on my qualifications or credentials as a writer. (And just because I don't normally bold every other word that I post does not mean that I don't know how to use bold tags.)
BTW, if you look far enough back in my posting history, you'll see where I responded to comments about a book that I co-authored, and that was reviewed right here on Slashdot. This would have been late 2004 or early 2005, IIRC. I'm happy to wait while you go find the review and comments. I'm sure with your mighty sleuthing skills (*eyeroll*) it won't take you long.
Il n'y a pas de Planet B.
And don't forget the *deliberate* security holes placed in close software. A link that comes to my mind: http://en.wikipedia.org/wiki/N...
You do realize that encryption is security through obscurity ... right?
No, it's not. The major difference is, that with a proper cryptosystem, if someone discovers your key, you can just switch to a new key and you're as safe as you were (not considering collateral caused by key leak). With security through obscurity, the once the genie is out of the bottle, you won't make it safe without changes to the design of the system.
As someone said, the ignorance runs deep here.
I don't HAVE to say that your Hosts File Engine is crap, Spanky. Half the freaking Internet has already said it for me.
Your app doesn't do anything that any text editor with basic regular expression support can't do better already, and do so WITHOUT pegging a 4-core CPU.
And there is NO WAY IN HELL that I'm EVER going to let such an abomination override the OS task scheduler on any system I administer. That's just insane.
Il n'y a pas de Planet B.
The key issue with this is that many eyes did not check this code. One way to get many eyes is via university. Open source is great for learning about how existing code is written, including safe practices vs. "performance". Usually people are asked to review smaller pieces of code like kernel components as part of coursework. This demonstrates it is useful perhaps to consider other, less sexy bits. Note that changes are being committed over time so there is always new material.
See my journal, I write things there
How does linking to the top of the same thread help your case? Why do you keep doing that?
Hyperlinks are not magic. There needs to be some meaningful content at the other end for them to be of any use.
ProTip: Making a false claim which merely links to a repetition of the false claim does not make the false claim true.
Il n'y a pas de Planet B.
Encryption is meant to make the original text be obscure, however the means of encryption should not remain obscure.
That is true, but the problem with OpenSSL is that much of the code has been deliberately obscured.
I once tried to use part of the encryption codes from OpenSSL in another project - after awhile I gave up and realized that the original implementation (can't recall which one - might have been Blowfish) was cleaner, and easier to understand.
It seems that it in order to be included in OpenSSL it had been rewritten to conform to some coding standard that made it more fragile and less readable; I assume this was done because of some coding-hubris in the OpenSSL-team.
Here are some others that also have issues with the OpenSSL code-base:
http://article.gmane.org/gmane.os.openbsd.misc/211963
https://www.peereboom.us/assl/assl/html/openssl.html
So, I believe the conclusion is that "Open source can be safer - if done right".
Why are you so adamant that it was not "eyeballs". So they fizzed their own infrastructure and found the issue. The article you posted is scant on the details if the tool and a google search did not turn up any salient details on the tool. From the description it appears to be black box testing SSL/TLS for obvious overruns. Was this not open source software, we may not have had such a quick response to this issue.
with a hot chick giving him a blowjob, can't leave that part out.
Don't for get Oracle!
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
The comment in TFA about marketing seems dead on. I honestly cannot think of any other disclose security vulnerability that got it's own logo.
There are no reliable metrics that indicate FOSS is safer. None.
Can you propose a metric that would compare the "safety" of FOSS versus closed-source/proprietary software?
(I thought not.)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I think the grandparent was right. MS now is hugely better than the MS of 10-15 years ago.
Hugely worse is hardly imaginable.
"I'm not much interested in interoperability. I want substitutability. I want to be able to throw your software out."
No matter how narrow the bell curve, outliers are still gonna happen.
It is not the NSA's job to cause mudslides, or make peoples hair fall out.
It is NSAs JOB to crack (other peoples) security systems. You are not being paranoid, they are out to get you.
Of course, other agencies do this too ...
Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist
eventually lol.
"Many eyes makes bugs shallow" applies not only to people working on the buggy code itself, but also all the developers who use the code. Bugs are almost always almost found because of software behaviour, and in general bugs in closed or open software are equally likely to be discovered by end-users. Bug are far more likely to be found by developers though. Consider some different scenarios: (1) A bug is discovered because following the documentation on how to use some API doesn't work exactly as expected; a really bad bug because behaviour under normal conditions is wrong. (2) A bug is discovered because a developer makes an invalid call to an API and it doesn't error out gracefully; still a bad bug, but most developers are going to correct their code to use the API correctly, and maybe file a bug report if the problem is bad enough to break their software. In case (1) someone is always going to file a bug report, closed or open source doesn't matter. In case (2) is different; chances are a developer isn't going to bother submitting a bug report if the buggy code is closed source, they'll just write some validation around the API call to avoid the bug before it happens. If open source, this validation will probably be submitted as a patch upstream, or at least someone is likely to report the bug. But then there's case (3), heartbleed. What you've got here is a bug that for correct input works, no bug to file, for incorrect input appears to still work, so still no apparent bug, but for incorrect input it does extra stuff you don't know in advance to check for. A developer with a case (3) bug is far less likely to discover that bug. If the library is open, a developer debugging their code might step into the library code and see the problem, slightly increasing the likelihood of the bug being found in open source as compared to closed.
The point is that downstream developers count as 'eyes', and probably make up the majority of those eyes. Because of lower barriers to entry, open source projects when compared to their equivalent closed-source counter parts tend to have many more downstream developers. Even is the case of non-library, end-user application projects, other devs are write plugins, extensions etc. so this remains mostly true. The argument that the eyes don't exist is not true. The eyes may not be looking directly at the code, but the code's behaviour is being tested in a variety of other ways. Case (1) bugs are going to be found and reported regardless of whether the source is open or not. Case (2) bugs are probably equally likely to be found, but far more likely to be reported and fixed if the buggy code is open source if there is a downstream workaround. Case (3) bugs are hard to find either way, but are MUCH easier to fix in the open source world.
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.”"
Given the simplicity of this bug, it's not hard to imagine what the source code for the bug looked like given the behavior. It is also not hard to imagine that upon discovering the unexpected results, the bug was confirmed by looking at the source code. Maybe for this bug, looking at the source code was just a confirmation of what they already knew. For many other bugs, looking at the source code is necessary to efficiently figuring out what the code is actually doing.
I'm not saying that this exact bug was found because it was in open source code. I am saying that it is not hard to imagine how a bug like this would be easier to find in open source software than closed source software.
At my company we use open source software libraries for our commercial products. When we find anomalies, we are actually able to figure out if bugs are in our own software or in the open source libraries we use. In fact, we actually run static analysis tools on every piece of open source software that we use because we care about the security of our own applications. We don't use openSSL, but if we did, we may have actually found this bug. That wouldn't be possible if the source was closed.
I can't find any information about how Neel Mehta discovered the bug.
By looking at the source.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
OpenSSL has no competition at its core competency, so the team really has no motivation to deliver an iteratively better product, apart from their need to scratch an itch. FLOSS software projects tend not to operate in a competitive environment, where multiple OSS products are useful for the same thing and vie for placement. This is probably bad.
I definitely don't agree.
Take any rant against FLOSS, the first thing you'll hear is complaints about "too much choices to pick from".
Sorry, but you can both complain that there's too much choice (hard on the user) and at the same time not enough choice (hard on security).
In the case of encryption, OpenSSL is far from the only present library. Its IS indeed very popular, but it's not the only used library.
GnuTLS is another popular library, which wasn't affected by Heartbleed (not specifically by this bug. It's not without problems, but still).
Mozilla's NSS seem popular with browsers (Firefox and Chrome use it, probably others too -and not only browsers: Pidgin uses it too). Again a different library, popular too
And that's just he major libraries. Then there are ton of others to chose from.
Some written in higher level language (Botan is in C++) and some (I hope, I haven't tested them all) probably using some facilities to abstract away a few pitfall like buffer lengths.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
...Chalk it up to valuable experience...
According to this sort of argument, nothing bad ever happens. The Air France 447 crash will improve pilot training, the Boston Marathon bombing will improve race security...
This point of view gives us no insight in to how to improve things. It belongs in the 'not even wrong' category.
Excuse me? Time for a reality check here. Someone appears to have the time to troll someone *200+ times* in a single day. Just who might that actually be, APK? I'm pretty sure that it's not me who's been doing that.
You have a really bad habit of seeing yourself in the mirror and claiming the reflection is a picture of someone else.
Il n'y a pas de Planet B.
I'll bet that I've more accrued vacation days from my job right now than you've ever actually worked in your whole useless life.
I could go on vacation *today* and not have to go back to work until the second week of August. And get paid for every single day of that time.
Il n'y a pas de Planet B.
One Google researcher and two Codenomicon researches disclosed this together. Funny how that was left out.
BTW, absolutely none of the AC posts in this thread were posted by me. In fact, I was asleep at the time those were made, having gone to bed about 20 minutes after I made the "Uh, What?" post (~2350 Central European Time), and not getting up until about 30 minutes after the AC grandparent of this post (~0830 CET).
Il n'y a pas de Planet B.
I suspect you meant that sarcastically, but if system software (meaning OS kernels, network stacks, device drivers, etc.) were written in better languages, our computer systems could be far safer and more robust, quality of life could be better, and the benefit to productivity and the global economy could be substantial.
For the computing industry, it is one of the great tragedies of our time that C and its derivatives have become so entrenched. There is absolutely no reason we can't have a systems programming language that offers the necessary low-level control without the limited programming model, error-prone syntax and weak safety features of C.
Unfortunately, it is momentum and ubiquity that keep most of the industry using C and its brethren, not technical merit. The vast ecosystem surrounding C is hard to beat for scale. There is promising work being done in some places, Rust for example, but I know of no practical alternative that is ready for production use today.
Of course, OpenSSL itself isn't running at the level of an OS kernel, so it doesn't need the same degree of low-level access anyway. But there is a wider point here about much more than just OpenSSL.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
APK, your *only* reputation is that of a spammer, troll, crapflooder, liar, and bully.
Itching for another trip down Memory Lane, eh? Well, then, here's what some folks at ArsTechnica thought of you ca. 2000-2001:
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=324090429
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=779092009
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=508099016
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=666096306
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=583094285
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=901092665
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=112093523
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=106095103
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=723095213
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=624098213
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=570092603
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=302095503
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=937096103
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=796095503
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=749092603
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=757093113
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=769092603
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=451098103
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=969090603
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=420096503
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=165093103
http://episteme.arstechnica.com/6/ubb.x?q=Y&a=tpc&s=50009562&f=12009443&m=437097503
Il n'y a pas de Planet B.
...get back to me in 100 years.
"The wisdom of the Patriarchs was that they *knew* they were fools." --Master Foo
The issues, whether it be closed / proprietary or open source is two fold:
1) Competency of the person writing the code or making the design changes.
2) Competency of the person who is reviewing the work to understand potential issues surrounding the design and, as applicable, the implemented code.
A developer SHOULD never be a final reviewer of their own work. They can double check their work, clean it up, verify it meets coding standards.. But, ultimately, it comes down down to the one or more competent reviewers to study the work.
When one writes a paper or a long-winded post and try to review our work immediately after it is written, the brain will, by nature, fill in the gaps. If you have to critically review your own work, walk away for a day or two and then come back and tackle the assignment. You will be amazed at the errors you missed before.
FOSS is not any more safer than proprietary code if nobody who understands has the capability to understand the code and issues actually looks at it critically. A few years ago, the OpenSSL team achieved FIPS 140-2 compliance which was a major undertaking and achievement. I haven't yet checked, but did the version affected by Heartbleed pass FIPS 140-2 certification as a cryptographic token? Or, did they never resubmit the code for recertification? I would suspect it was never resubmitted as the cost for certification is too high. Had it been done, this MIGHT have been exposed long before now.
What WAS done correct was the rapid response once the problem was identified. This is something that corporations may drag their heels on as there a legal and financial repercussions when a vulnerability is found - even worse with an live exploit in the wild. They have to perform a risk analysis (on all levels) and determine if a fix is to happen at all. At the same time, corporations that rely on any system without a service level agreement that covers such issues take a major risk. This is where reliance on FOSS can bite you and why many corporations still maintain critical systems on proprietary operating systems and commercial software.
Given your recent track record with me and other Slashdotters--and the fact that Jeremy's and Jay's websites appear to be alive and well--I am going to assume that you're at least mischaracterising and most likely just outright lying.
Il n'y a pas de Planet B.
I'll repeat what I've already said elsewhere:
1. I've yet to find a single case where one of your host files trolls was even remotely on-topic.
2. Your "host files engine" is a useless, CPU-sucking piece of crap, and I am very far from being the first one to say this. (Furthermore, you actually boast about its horrid performance as if it were something to be desired.) In addition, it overrides the Task Scheduler for no good reason whatsoever. That in my opinion qualifies it as something I would never in a million years permit anywhere near any machine that I use or administer; IOW it is for all intents and purposes malware and no amount of your ranting and raving and trolling and crapflooding is ever going to change this fact.
Il n'y a pas de Planet B.
APK, you appear to be capable of making 2 and only 2 sorts of statements:
1. Mischaracterisations
and
2. Lies
You seem to prefer the former, I guess because in your twisted world they're more difficult for someone else to disprove.
Il n'y a pas de Planet B.
I've already made it crystal clear that I am utterly certain that you are engaging in gross mischaracterisation, as this is one of your trademarks.
Like I said before: If APK tells us that the sky is blue, I'm going to assume that this is a lie until I look out the window and see it for myself.
Il n'y a pas de Planet B.
IOW you need to offer proof that this is what happened.
ProTip: Linking to one of your own posts does not constitute proof.
And like I've said before, as far as I can tell, every single one of your host files spamvertisements has been off-topic.
Since they are nothing but spamvertisements for a crapware host files app that nobody in his right mind wants to allow anywhere close to his system, your posts are by definition useless and off-topic. Q.E.D.
Il n'y a pas de Planet B.
The same argument can be applied to government. Just because all laws are visible to the public doesn't mean we don't ever put and keep bad laws in effect. The solution to bad laws is not hiding them, it's more publicity. Similarly, more review on each commit would help the OpenSSL project.
``OK, so ten out of ten for style, but minus several million for good thinking, yeah?''
Your usermode app *subverts* normal process scheduling. You *bragged* about this until it was pointed out that this is a really, really bad thing to do.
All I can see is that those two individuals' websites appear to be alive and thriving.
And how you can try to portray getting kicked off Ars at least 4 times as some sort of victory is pretty silly.
But we've come to expect mischaracterisation from you much as we'd expect cowflop from the wrong end of a cow.
Il n'y a pas de Planet B.
Why are you so adamant that it was not "eyeballs". So they fizzed their own infrastructure and found the issue. The article you posted is scant on the details if the tool and a google search did not turn up any salient details on the tool. From the description it appears to be black box testing SSL/TLS for obvious overruns.
And such testing would find such a bug equally well in proprietary or open source code. It seems fairly clear that the bug was not discovered by someone reading the source code, despite the code being available for two years and the code being absolutely critical to networking.
The value of many eyeballs is often exaggerated. Few users are developers. Few developers are qualified readers.
At my company we use open source software libraries for our commercial products. When we find anomalies, we are actually able to figure out if bugs are in our own software or in the open source libraries we use. In fact, we actually run static analysis tools on every piece of open source software that we use because we care about the security of our own applications. We don't use openSSL, but if we did, we may have actually found this bug. That wouldn't be possible if the source was closed.
That is not true. At past jobs where we used proprietary libraries in our commercial products, I always advocated for buying the more expensive source licenses rather than the less expensive binary only licenses. We even chose vendor A over vendor B due to A have a source option and B not having one. Fortunately all the libraries we used had source options, obviously YMMV. Management was always reluctant until we found and resolved problems in these proprietary libraries just as you describe doing in open source. Management quickly became believers in buying the source licenses so that our fate was not in a 3rd party's hands.
Specifically? Everything, except for the errors and mischaracterisations.
Il n'y a pas de Planet B.
Proprietary or open seems irrelevant to this discovery.
You can't make such conclusions from one bug.
Good thing I was commenting on only this one bug. That said, one can absolutely make the statement that fuzzing and other penetration testing works equally well on proprietary and FOSS code. The binary being tested doesn't care about the nature of it license.
Bugs will happen, and bugs will go unnoticed. The question is about whether the open source nature of a piece of software decreases the frequency of those events.
No one is arguing whether bugs will occur and go unnoticed. What is being argued is that the value of the "many eyeballs" concept is often exaggerated. Few users are developers. Few developers are qualified readers.
Well, since you asked:
Currently that's 5 Insightful mods, 1 Overrated, and 1 Troll.
I start at 1 when logged in, and I get an extra +1 for having excellent Karma.
What's "Karma", you ask? That's something you don't really need to worry about, since you are too big a coward to create an account and log in to it before posting, and even then, you need to post stuff that people think is useful, informative, insightful, which you don't seem capable of doing, so my advice is not to bother.
Il n'y a pas de Planet B.
You started your own janitorial service? Congrats.
Il n'y a pas de Planet B.
I was talking about you, APK. Zontar is not the one obsessively flooding the discussion with offtopic incoherent ramblings. It's not what you say, it's what you do.
Apparently you've figured out that I don't want or need to post AC in response to your trolls, APK.
I've been having a field day finding your slimy little trails all over the Internet and exposing you for the lifelong spammer, bully, troll, crapflooder, and liar that you are.
Why should I not want to receive credit for unearthing all these wonderful facts about yourself that you've been leaving lying about for the last decade or more?
Besides, it's been giving me something to take my mind off cigarettes--I decided to quit on Monday after being a smoker for 30+ years.
This is working out really well for me, too--every time a I get a craving for a smoke, I just hit the Google again and find something new to smoke you with, instead. :D
Or maybe next time I'll switch to Bing and see what they've got on you, as well.
Il n'y a pas de Planet B.
Name some of the "spots" where you've lived outside the US, and tell us a little about them.
I'd like to compare notes.
Il n'y a pas de Planet B.
Safer != Perfect
But it's not safer. It's less safe.
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.
And so the excuse making comes.
You're apparently the only person visiting this site who can't see that the TrollingForHostFiles account was created specifically in your honour, AFTER you started trolling me and crapflooding any and all threads I posted to.
And I've made absolutely no secret of TFHF's origins, which kind of deflates your sockpuppet conspiracy theories.
Oddly enough, the TFHF account already has positive karma, which means somebody's been modding up its posts in spite of the fact that it's an acknowledged alter ego. And I'm extraordinarily pleased to say that I (Zontar) have not had mod points since the TFHF account was created, so those upmods are not coming from me.
Il n'y a pas de Planet B.
No question the heartbleed thing is a huge and embarassing problem.
The biggest of the internet era. Only outdone by the Y2K category of bugs.
And the origins of both are optimisations which are no longer necessary. For Y2K, back in the day saving 2 bytes repeatedly mattered. And for C, back in the day, saving a bounds check mattered. (And on top of that the Open SSL term believed creating their own malloc mattered.) Nowadays none of these optimisations are worth it. They should all be long gone.
It's everybody's failure that C hasn't been replaced as a systems programming language. It's ought to be a footnote in history by now.
I apparently didn't have time to troll someone TWO HUNDRED TIMES in a single day, whereas you OBVIOUSLY had time to do so, because you DID in fact do just that.
You must be weak in the head if you think that is not patently obvious to anyone observing these proceedings.
Il n'y a pas de Planet B.
One problem I see that is huge is in where it affects Android. It is an unfortunate reality that phone makers do not want to update or patch their phones as they would rather sell people new phones and carriers would rather extend contracts. So yes, perhaps I did understate it a bit.
There needs to be a push for phone makers to update their firmware NOW.
On, NO, they found a serious bug in a FOSS package, Oh NO, the proprietary fanboys are saying that the Sky is Falling! Meanwhile, a fix comes out on the day that the advisory is issued and the patch to the library is on several repositories that day. On April 7, the day of the CERT, Debian had a patch to the openssl livrary.
Have you heard of an old cliche that goes "learn from your mistakes". By your logic, no errors can ever be made and learned from.
"SO we bide our time, waiting for a purer kick to bloom and the future is still bleak, uncertain and beautiful" -GSYBE
Have you heard of an old cliche that goes "learn from your mistakes". By your logic, no errors can ever be made and learned from.
What we have here is a failure to learn from previous mistakes - this bug violates a number of basic principles in the development of secure software, and most of those principles were derived from hard experience.
I will agree that there is one thing to be learned here: The phrase "with enough eyes, all bugs are shallow" is simplistic wishful thinking, and potentially dangerous if mistaken for a realistic verification policy.
Hello Zontar sockpuppet - Zontar does this
Paranoid delusions - check.
Show us a post where I put up material on hosts where it doesn't apply.
All of them. Living in an alternative reality - check.
I would advice you try to take your meds on time and never skip them. It's really important.
I repeat: All of Slashdot is still waiting for you to show even one time you have ever posted your copypasta spamvert that it's been ON topic.
You post nothing but spam, trolls, attacks, mischaracterisations, half-truths, and plain old lies.
When you're called out on it, you resort to crapflooding.
Il n'y a pas de Planet B.
So you've never been outside the US.
Have you ever been outside New York State?
Have you ever even been outside the Syracuse city limits?
Il n'y a pas de Planet B.
Apparently in APK's world, all ACs are Zontar and all logged-in Slashdotters are also Zontar.
Whaddaya think, AC buddy? Should I feel honoured?
Il n'y a pas de Planet B.
Have you found the book review yet?
Il n'y a pas de Planet B.
Posting a link to yet another copy of a falsehood does not make the falsehood true.
Il n'y a pas de Planet B.
One plan I was considering for TrollingForHostsFiles was to have him try to convert APK to Buddhism, but I'm still a bit too jittery from nicotine withdrawal to come up with any suitable rhymes.
He's awfully quiet today--I hope they've not already managed to block him.
Il n'y a pas de Planet B.
Dude, are you like 12 years old or something?
Il n'y a pas de Planet B.
You just keep linking to your own posts, as far as I can see.
You seem to have trouble understanding that linking to a copy of a falsehood does not make the falsehood true.
Il n'y a pas de Planet B.
Show us a post where I put up material on hosts where it doesn't apply.
You can't, can you? Nope - That makes YOU a liar.
---
I have already explained why your crapflooding and spamvertisements are by definition off-topic. It's up to you to show where a single one of them was on-topic and you are never going to do this because it is simply not possible.
"He's effectively turning off the Windows process scheduler" - FROM -> http://slashdot.org/comments.p...
Don't misattribute that to me, as I wasn't the one who said it. (It's true that I happen to agree with the statement, but that is not the same thing as having said it.) In any case, your objection has already been answered numerous times. The fact that you continue to ignore these responses does not mean they weren't made or that they weren't valid.
You can't explain WHY Jeremy Reimer and Jay Little's websites were removed by CrystalTech &/or Shaw CA hosting providers
IF I'm "so bad", why'd THAT happen to 'em? apk
We are still waiting for some evidence (other than your say-so) that this ever even happened. Until you offer such evidence, nobody is going to believe that it ever did happen anywhere outside your own fevered imagination.
As for me changing the subject, let's review that bit, shall we?
APK: "I live on my own since the 80's & have my own spot however, occasionally while travelling worldwide for work I lived TONS of spots in the world (or for play too of course) or between jobs..."
Zontar: "Name some of the 'spots' where you've lived outside the US, and tell us a little about them."
APK: [Posts a response with the subject line "Zontar *tries* to change the subject? LMAO!" in which he does not answer Zontar's question.]
The only conclusion that a reasonable person can make after seeing this is that APK lied about having travelled and lived outside the US.
Il n'y a pas de Planet B.
Or you could start using Mozilla NSS (mod_nss). Not only independently written, it also aggressively protects private keys unlike any version of OpenSSL/SSLeay does.
Kriston