Forgot your password?
typodupeerror
Open Source Bug Security

How Does Heartbleed Alter the 'Open Source Is Safer' Discussion? 582

Posted by Soulskill
from the or-at-least-marginally-less-unsafe dept.
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?"
This discussion has been archived. No new comments can be posted.

How Does Heartbleed Alter the 'Open Source Is Safer' Discussion?

Comments Filter:
  • by symbolset (646467) * on Tuesday April 15, 2014 @05:19PM (#46761113) Journal
    Which is run by a former Microsoft executive who was in charge of security. I guess he can gloat about being personally responsible.
    • by Thiarna (111890) on Tuesday April 15, 2014 @07:03PM (#46762099)

      I had to dig for direct connections between Codenomicon and Microsoft, but the chairman of the board seems a fairly strong link. The way Codenomicon have behaved in this has seemed reckless, I've never seen a bug so heavily marketed. The stats floating around initially seem to be way off the mark - to begin with quotes were of 66% of web servers being affected, later revised to 17% running affected versions. Both these numbers look too round to be anything other than made up.

    • by msauve (701917) on Tuesday April 15, 2014 @07:34PM (#46762313)
      Gloat? About what? This only provides proof of the benefits of open source - a significant flaw was discovered, which is exactly the claimed advantage - the more eyes, the better.

      Anyone who would claim that proprietary software is somehow more secure is making a huge leap - there are only a few eyes, if any, looking for unreported issues - so there may be even more serious issues which have existed for much longer, which only a few bad guys know about. If MS or anyone else thinks that their proprietary SSL implementation has no security breaches, let them put a guarantee with full financial liability behind that thought.
      • Gloat? About what? This only provides proof of the benefits of open source - a significant flaw was discovered, which is exactly the claimed advantage - the more eyes, the better.

        But it wasn't found by eyes, in the source. It was found by automated testing tool that would have just as easily found it in closed source.

  • Wat? (Score:5, Insightful)

    by Anonymous Coward on Tuesday April 15, 2014 @05:21PM (#46761129)

    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.

    • Re:Wat? (Score:5, Interesting)

      by tysonedwards (969693) on Tuesday April 15, 2014 @05:44PM (#46761367)
      It is a double edged sword. Because one can see the code, there is visibility into the process. Because OpenSSL is such a common tool and is arguably vital to the function of the Internet as we know it, this sort of a bug really is one of those "worst case scenarios" PR wise, as opposed to being cleanly swept under the rug as is possible in the case of many Closed Source 0-day vulnerabilities.

      The problem here is that people have been using the argument that Open Source is better because these issues can't happen "because" of the visibility. And the argument "Open Source is inherently safer" has been very heavily damaged by Heartbleed and now ranks up there with "Macs don't get viruses" and "Women are worse drivers".

      If this happened in Microsoft, Adobe or Oracle Land this would be "yet another 0-day" and largely ignored by the public. Because it is in an area with such a vocal group of people spouting "Impenetrable" for decades, it all of the sudden becomes quite newsworthy in a way that "yet-another-remote-code-execution-with-privilege-escalation-in-Acrobat-Reader" vulnerability doesn't.

      And if you doubt any of this for a moment, have you ever heard the name of the developer who was at fault for introducing a bug into Flash on the local news? Now did you hear the name "Robin Seggelmann" in connection to Heartbleed?
      • Re:Wat? (Score:5, Insightful)

        by Arker (91948) on Tuesday April 15, 2014 @06:25PM (#46761787) Homepage
        "The problem here is that people have been using the argument that Open Source is better because these issues can't happen "because" of the visibility."

        No, just no. No one with any sort of a clue ever argued these issues cannot happen with Free Software. It's good practice, it helps, but it's no silver bullet. That's just as true as it ever was and this news in no way contradicts that.

      • by Livius (318358)

        "Open Source is inherently safer"

        Yes.

        Open source absolutely safe?
        No.

      • Re:Wat? (Score:5, Insightful)

        by TsuruchiBrian (2731979) on Tuesday April 15, 2014 @07:39PM (#46762349)

        The problem here is that people have been using the argument that Open Source is better because these issues can't happen "because" of the visibility.

        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.

        And the argument "Open Source is inherently safer" has been very heavily damaged by Heartbleed and now ranks up there with "Macs don't get viruses" and "Women are worse drivers".

        The argument "seatbelts make riding in a car safer" is not "heavily damaged" by someone dying in a car accident while wearing a seatbelt.

        Imagine this code was closed source. Whats the desired outcome? That hackers never stumble upon the bug and the it goes unnoticed forever, and therefore never needs to be fixed?

        • by perpenso (1613749) on Tuesday April 15, 2014 @11:56PM (#46763939)

          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... [readwrite.com]

        • 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.

          I see another lesson here. We (i mean, people in the IT industry) rely on ultra sensible piece of code like openssl, and we blindly use it. We don't question much about how the way this software is created and by who. That's the problem. We put our trust on something we know very little about. Discovering the small team coding openssl is quite a surprise to me. I feel really ashamed to discover this that late. How stupid is that... The feeling that "because so many smart people use openssl must imply strong

      • by jc42 (318812)

        Because OpenSSL is such a common tool and is arguably vital to the function of the Internet as we know it, this sort of a bug really is one of those "worst case scenarios"

        True, but the main lesson to learn from it can be summarized by the old cliche saying "Don't put all your eggs in one basket". The warning about a "monoculture" also applies here. If one specific piece of software is universally used, even a minor bug in it can be a widespread disaster. If people had any sense, the very fact that something is so popular and widespread would be a strong argument for duplicating its functionality with independently-developed code.

        Of course, in reality we humans tend to

    • Re: (Score:2, Insightful)

      by clarkkent09 (1104833)

      True, but it is also easier for malicious people to find vulnerabilities when they have the source code. There are other disadvantages, a broad developer base allows vulnerabilities to be deliberately introduced more easily and it's harder to enforce standards etc.

      I searched and couldn't find a good study or any reliable evidence either way. There is good and bad open source software and there is also good and bad commercial software. Posting with absolute certainty that open source is more secure will get

      • Re:Wat? (Score:5, Insightful)

        by F.Ultra (1673484) on Tuesday April 15, 2014 @05:55PM (#46761495)
        You seriously think that black hats bother with reading millions of lines of code in the hope of finding an exploit when all they have to do is play with the data sent to services/applications and see if it misbehaves. Which is why exploits are equally found among closed and open softwares.
        • Well, you wouldn't start by reading millions of lines of code but it certainly helps to have access to it. Especially for people with serious resources, governments etc.

    • Re: (Score:3, Insightful)

      by alex4u2nv (869827) *

      Correct -- I could imagine that there are lots of "heartbleeds" in closed source software that can and will be exploited. Whether it becomes public and puts pressure on the development staff to fix, is another story.

  • Mr Fixit (Score:5, Insightful)

    by frisket (149522) <peter AT silmaril DOT ie> on Tuesday April 15, 2014 @05:22PM (#46761137) Homepage
    All that has happened is that FLOSS has been shown to react faster to security revelations than closed or proprietary softwarre.

    That's fine with me.

    • Re:Mr Fixit (Score:5, Insightful)

      by iluvcapra (782887) on Tuesday April 15, 2014 @05:35PM (#46761273)

      That it reacts fast is good. That the bug could be audited in the source, in public, is good.

      We should remember that FLOSS reacted very quickly to the "revelation," but the bug itself has been sitting there for years, which isn't really supposed to happen.

      It's nice we know how long it's been there, and can have all kinds of philosophical discussions about why the OpenSSL folks decided to write their own malloc.

      Also OpenSSL was effectively a monoculture and just about every SSL-encrypted internet communication over the last two years has been compromised. 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.

      • Re:Mr Fixit (Score:4, Insightful)

        by CajunArson (465943) on Tuesday April 15, 2014 @05:54PM (#46761481) Journal

        " 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.

        • by almitydave (2452422) on Tuesday April 15, 2014 @06:26PM (#46761809)

          " 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 [reference.com]: 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.

          • OK so if you are using "compromise" to mean "Every SSL session in the past 2 years was potentially vulnerable to danger", then I guess that's true in the sense that almost every computer is compromised since there are probably many unnoticed security holes in just about every OS and commonly used library.

    • Re: (Score:3, Interesting)

      by Desler (1608317)

      Which is a ridiculous statement to make in this situation. That's like patting your security company on the back for not noticing for two years that someone was secretly stealing money out of your bank vault and they only did something after being told by a third-party that there was a problem. But hey they reacted fast two years after the fact, right?

  • 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.

    • by Cid Highwind (9258) on Tuesday April 15, 2014 @05:56PM (#46761517) Homepage

      "Yes, we can trace the changelogs in the software & note who was checking the changes and missed them, but that all can be circumvented."

      Actually it can't. That's kind of the point of git.

      "The fact is we don't know if Heartbleed was an honest mistake or not...we don't know who knew and when..."

      We do know who and what and when, because the person who wrote it and the person who signed off on it have commented publicly about the bug.

      Maybe you're thinking of Apple's "goto fail" SSL exploit where we really don't know who or what or when and probably never will because it's not likely Apple is going to release their RCS logs.

      • by Karlt1 (231423)

        Maybe you're thinking of Apple's "goto fail" SSL exploit where we really don't know who or what or when and probably never will because it's not likely Apple is going to release their RCS logs.

        Well we know the when and we know the what .

        http://www.theguardian.com/tec... [theguardian.com]

      • > Actually it can't. That's kind of the point of git.

        Unfortunately, many git users keep their SSH keys unencrypted on their local hard drives or on network accessible home directories. This means that a careless git admin may have their SSH keys stolen by quite amateur crackers, and leave the public repositories open to quite malicious changes. I've had precisely such discussions with personnel who insist that they trust the people they work with and they have a firewall, so they're not at risk.

  • by sandytaru (1158959) on Tuesday April 15, 2014 @05:23PM (#46761141) Journal
    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.
    • by unimacs (597299)

      More eyeballs usually do make bugs more shallow, but only if the eyes know what to look for.

      And only if a significant number of sophisticated and knowledgeable eyes have the time and interest to dig through lines and lines of code looking for vulnerabilities.

      The reality is that the majority of eyeballs looking at code are the ones that have other reasons to be looking at it. They aren't necessarily looking for vulnerabilities but maybe they spot something.

      The eyes that might be interested in scouring code looking for vulnerabilities could be the ones wanting to exploit them rather than fix t

    • by unixisc (2429386)

      The 'millions of eyeballs' meme is just that. How many people actually know how to read code? Just b'cos it's open doesn't mean that it's comprehendible, and therefore, the fact that the code is open & out there doesn't have that much of an advantage, particularly when it's such complex code.

    • Not saying that heartbleed wasn't / isn't a huge problem, but I think most analysts would agree that by far the biggest security problem is (collectively) bad corporate or bad individual security practices. I realize that heartbleed is not the same in that it is not within the control of the end user, but still, things like poor passwords, clicking on every email attachment, etc., are much bigger aggregate problems.
  • by slincolne (1111555) on Tuesday April 15, 2014 @05:25PM (#46761157)
    It's probably better to let the situation run on a bit longer before people start criticising Open Source.

    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.

  • by bazmail (764941) on Tuesday April 15, 2014 @05:25PM (#46761161)
    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.
    • Re: (Score:3, Insightful)

      by jklovanc (1603149)

      What we need are intelligent bots to constantly trawl source repositories looking for bugs.

      If we had bots that intelligent they would be intelligent enough to write the code without bugs.

      • by suutar (1860506)
        I dunno. Coverity can catch a lot of stuff (in fact, I recall reading that they had to limit what they caught on the basis of what they could explain to the programmer, because confusing the programmer led to incorrect 'false positive' decisions). I don't know if it would have caught this, but it would be worth trying.
      • by Error27 (100234)

        This code could have easily been detected with static analysis. It's a common failure pattern. You just taint data from the network as untrusted and look for when invalid use cases.

        I do static analysis like this on the linux kernel for a living.

    • by unixisc (2429386)

      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.

      Not just that, the only people who'd find such bugs are the people actually working on those programs. Usually, not their downstream users.

    • by F.Ultra (1673484)
      Well some one must have been looking since the bug was found?
    • by quantaman (517394)

      I don't think Heartbleed says anything fundamental about open source security, but it might alter the discussion of how certain low level packages are managed. By any measure OpenSSL is a very important package, but it's also a bit generic. It has a very defined role that everyone needs, but I'm not sure how many people really have a motive to work on it in specific. It might be that the community needs to find a way to devote more resources to maintaining and auditing those packages.

  • by kurisuto (165784) on Tuesday April 15, 2014 @05:25PM (#46761165) Homepage

    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".

    • by Zocalo (252965) on Tuesday April 15, 2014 @05:46PM (#46761381) Homepage
      This, and I suspect a lot of shilling by proprietary software vendors playing up the "many eyes make bugs shallow" thing. This wasn't so much a failure of the open source model as it was a failure to properly vet commits to the code of a project before accepting them into the main tree, and that could happen just as easily on a closed source development model as an open source one. That might be OK for small hobby projects, and perhaps even major projects that don't have quite so major ramifications in the event of a major flaw, but hopefully this will serve as a wake up call for projects that aim to form some kind of critical software infrastructure. For such projects requiring that commits be reviewed and "signed off" by one or more other developers would perhaps have caught this bug, and others like it, and could perhaps work very well in conjuction with some of the bug-bounty programmes out there. Of course, "Find a flaw in our pending commits, and get paid!" only works if the code is open for inspection...
  • by jonwil (467024) on Tuesday April 15, 2014 @05:26PM (#46761179)

    How do we know that serious security flaws don't exist in the SSL implementations used by Microsoft or other proprietary vendors?

  • It doesn't. (Score:5, Insightful)

    by BronsCon (927697) <social@bronstrup.com> on Tuesday April 15, 2014 @05:26PM (#46761181) Journal
    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.
    • And we know this happens - researchers learn about zero-day exploits in the field everyday. Whats the odds that we learn about all of them? Zero, I'd wager.

      People who do really deep audits of a system after a breach know what this is like. When you get that feeling that you are up against something new, or something unreported.

      • by BronsCon (927697)
        And anyone who's serious about security is taking mitigation steps for every scenario that can conceive, known exploit or not. That should be SOP whether or not you have source available.
    • by Tontoman (737489) *
      It is also trivial to disassemble and decompile closed-source software. Starting with the names of routines from the public entry points, trace arguments through the code, and thus find potentially exploitable defects. It's almost as easily as the rather obscure "style" of the openssl code that had the heartbleed bug. The problem is, there is a chilling effect because of laws and uncertainty surrounding reverse engineering: http://www.chillingeffects.org... [chillingeffects.org] . Therefore, perhaps only criminals will do it
    • Re:It doesn't. (Score:4, Interesting)

      by ratboy666 (104074) <fred_weigel AT hotmail DOT com> on Tuesday April 15, 2014 @06:17PM (#46761723) Homepage Journal

      This myth gets trotted out again. It is arguably easier to find exploits without source. The source distracts from the discovery of an exploit. The binary simply is. The black-hat is looking for a way to subvert a system. Typically she is not interested in the documented (by source or documentation) functionality. That simply distracts from the issue which is finding out what the software actually does, especially in edge circumstances.

      This is what fuzzers do. Typically not aware of the utility of the program, they simply inject tons of junk until something breaks.

      Source availability tends to benefit people auditing and repairing more than black-hats.

      Yes, it took years for heartbleed to surface. If heartbleed (or a defect like it), was discovered due to a code audit, that speaks to the superiority of open source over closed source. If this defect is found by fuzzing or binary analysis, it is much harder to repair, as users are now at the mercy of the holder of the source. Build a matrix of Open/Closed Source vs. Bug found in Source, Bug by fuzzing/binary analysis.

      Bug found in source vs Closed Source is not applicable, giving three element. Found in source vs. Open Source (where the bug will be repaired in the source by anyone). Bug found by fuzzing... where the bug will be repaired in the source by anyone (Open Source) or the Vendor (Closed Source).

      The question then is (as I started the article): Is it easier to find bugs by source inspection? Assume big threats will HAVE the source anyway. If it was easy to find by inspection, it would be easy to fix (for examples: OpenBSD continously audits, and security has been a priority at Microsoft for the past decade). Fuzzing and binary analysis is still the preferred (quickest) method, giving the edge to Open Source. The reason is simple -- the black-hat cares about what is actually happening, and not what the source says is happening.

  • Not enough eyes (Score:5, Insightful)

    by Phillip2 (203612) on Tuesday April 15, 2014 @05:27PM (#46761183)

    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.

  • Uh, what? (Score:5, Insightful)

    by Zontar The Mindless (9002) <plasticfish@info.gmail@com> on Tuesday April 15, 2014 @05:29PM (#46761209)

    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.

  • by Anonymous Coward on Tuesday April 15, 2014 @05:30PM (#46761225)

    What hasn't been found in closed source software because it is too inconvenient to look?

  • What if... (Score:4, Insightful)

    by chiefcrash (1315009) on Tuesday April 15, 2014 @05:35PM (#46761277)
    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...
  • by Todd Knarr (15451) on Tuesday April 15, 2014 @05:36PM (#46761287) Homepage

    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.

  • This was positive (Score:5, Interesting)

    by danheskett (178529) <{danheskett} {at} {gmail.com}> on Tuesday April 15, 2014 @05:37PM (#46761289)

    Heartbleed was positive for the world. The bug was found by code review, twice independently in a short period of days. It was patched rapidly across a hundred different versions and platforms, and now the world is vastly more safe. The system worked exactly as it should.

    It is entirely likely that Heartbleed is out there for a closed platform. Or worse. And it's likely that it is being exploited right now by not only our own Government in the US, but our foreign rivals for economic and political gain. And what's worse, there is probably code out there that is defunct, full of Heartbleeds, bleeding exploits into the wild uncontrollably.

    The only downside it exposed is that some projects have a lock on what they do. OpenSSL is so good that everyone uses it, and no one is seriously interested in forking it or doing a new implementation.

    • by dublin (31215)

      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? Ho

    • Nobody was seriously inerested in forking it... But the OpenBSD people have now gotten their claws into it, and chances are it's gonna be fixed bigtime .... or else!.

      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.

      .. and that is the power and freedom of Free, and Open Source software.

  • by infernalC (51228) <matthew.mellon@NOSPam.google.com> on Tuesday April 15, 2014 @05:41PM (#46761339) Homepage Journal

    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.

  • Also (Score:4, Informative)

    by danheskett (178529) <{danheskett} {at} {gmail.com}> on Tuesday April 15, 2014 @05:41PM (#46761341)

    I would like to just point out this is a huge win in my book for Debian. Those of us running an all Debian oldstable environment, getting backported security patches, and sticking with the tried and true version of OpenSSL instead of that newfangled 1.0 code release got to write nice letters to our customers saying we still don't use Windows and we were never vulernable.

    LONG LIVE OLDSTATBLE.

  • 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/peopl

  • 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.
  • by Eravnrekaree (467752) on Tuesday April 15, 2014 @06:17PM (#46761719)

    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.

  • by mfh (56)

    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.

  • 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

  • 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.

  • "Ever since the "Heartbleed [smh.com.au]" 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."

    Company | Codenomicon: "Howard A. Schmidt, Chairman of the Board .. 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 [codenomicon.com] ."
  • 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 dog

  • 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

  • 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 reliab

  • It doesn't. (Score:5, Insightful)

    by nashv (1479253) on Tuesday April 15, 2014 @06:55PM (#46762045) Homepage

    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.

  • by Kremmy (793693) on Tuesday April 15, 2014 @07:13PM (#46762175)
    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.
  • by Opportunist (166417) on Tuesday April 15, 2014 @07:20PM (#46762223)

    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.

  • by ikhider (2837593) on Tuesday April 15, 2014 @09:10PM (#46762961)
    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.
  • by Bugler412 (2610815) on Tuesday April 15, 2014 @10:13PM (#46763385)
    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
  • by hackus (159037) on Tuesday April 15, 2014 @10:54PM (#46763631) Homepage

    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.

RADIO SHACK LEVEL II BASIC READY >_

Working...