Forgot your password?
typodupeerror
Security

New OpenSSL Man-in-the-Middle Flaw Affects All Clients 217

Posted by timothy
from the disclosure-of-diclosure dept.
Trailrunner7 (1100399) writes 'There is a new, remotely exploitable vulnerability in OpenSSL that could enable an attacker to intercept and decrypt traffic between vulnerable clients and servers. The flaw affects all versions of the OpenSSL client and versions 1.0.1 and 1.0.2-beta1 of the server software. The new vulnerability could only be exploited to decrypt traffic between a vulnerable client and a vulnerable server, and the attacker would need to have a man-in-the-middle position on a network in order to do so. That's not an insignificant set of conditions that must be present for a successful attack, but in the current environment, where open wireless networks are everywhere and many users connect to them without a second thought, gaining a MITM position is not an insurmountable hurdle. Researchers who have looked at the vulnerable piece of code say that it appears to have existed, nearly unchanged, in the OpenSSL source since 1998.'
This discussion has been archived. No new comments can be posted.

New OpenSSL Man-in-the-Middle Flaw Affects All Clients

Comments Filter:
  • by Anonymous Coward

    "but in the current environment, where open wireless networks are everywhere and many users connect to them without a second thought"

  • Neat (Score:5, Insightful)

    by Anrego (830717) * on Thursday June 05, 2014 @10:51AM (#47171819)

    But if you have a man in the middle position, most of those same users would have just clicked "ignore" or typed yes to the "connect anyway" prompt.

    • Re:Neat (Score:4, Informative)

      by bluefoxlucid (723572) on Thursday June 05, 2014 @12:51PM (#47172857) Journal

      The summary is actually ridiculous.

      The summary suggests SSL is useful without a man-in-the-middle. SSL protects against eaves droppers on your network; but any eaves dropper can become a MITM. ARP cache poisoning is a common technique; on switched networks, you cannot eaves drop without ARP cache poisoning or ARP flooding. Hubbed networks are similarly easy: packet the target with IP=DEFAUTGATEWAY MAC=YOU and it will start addressing default gateway packets to you (routing works by putting the destination IP on a packet, but the default gateway's MAC on the frame; you enter the IP address of the router, and the OS runs an ARP request to find its MAC).

      It's entirely unlikely that SSL does anything if there isn't a man in the middle.

    • And yet everyone threw a hissy fit when Firefox first made it a massive PITA to use self-signed / untrusted certs.

      Honestly their implementation is pretty good; you can get through it, but blindly clicking will result in the cert being rejected.

  • Versions (Score:3, Insightful)

    by Anonymous Coward on Thursday June 05, 2014 @11:01AM (#47171915)

    Just to be clear, versions 1.01 and 1.02(beta) is the same as saying "Any OpenSSL version released since early 2012", right? It sounds like the summary is trying to downplay the threat a little bit.

    • Re:Versions (Score:5, Informative)

      by GameboyRMH (1153867) <[moc.liamg] [ta] [hmryobemag]> on Thursday June 05, 2014 @11:08AM (#47171977) Journal

      That's right, it affects all versions that are anywhere close to current.

      • Re: (Score:2, Interesting)

        by Anonymous Coward

        especially after everyone panic-upgraded after heartbleed.

        • Re:Versions (Score:4, Insightful)

          by Zero__Kelvin (151819) on Thursday June 05, 2014 @02:05PM (#47173557) Homepage

          "especially after everyone panic-upgraded after heartbleed."

          You can leave out the "panic". Everyone upgraded. Appropriately. No need for the over-sensationalism.

          • by XanC (644172)

            That's not necessarily true. People may have "panic upgraded" who were using a supported and up-to-date (and not vulnerable) 0.9.8. People may have "panic upgraded" by building and installing the latest OpenSSL, not knowing that their distribution had pushed out a patched version of the version they had been running. Now, their OpenSSL might be totally outside of package management, and they could really be in trouble for this one, unless they're paying a lot of attention (which they aren't, or they woul

      • FreeBSD 9.0 uses OpenSSL 0.9.8q by default (though 1.0.1 is optionally available in the ports tree), which according the summary should be safe (from this attack at least).
    • Re: Versions (Score:3, Informative)

      by Anonymous Coward

      There are also stable releases of 0.9.8 and 1.0.0 which are still maintained for security updates. Many long-term-stable distros and even some recent network appliances don't use 1.0.1 because of the possibility that code churn and feature dev has made it less secure than 1.0.0. In this case they would be right.

      • by afidel (530433)

        Yup, our Linux based application firewall uses a security maintained 0.9.8 based build so we weren't affected by heartbleed. It looks like we'll need to make sure it's patched to 0.9.8za level to avoid the possibility of this being an issue.

  • This is awesome (Score:5, Insightful)

    by Jody Bruchon (3404363) on Thursday June 05, 2014 @11:01AM (#47171921)
    The more of these we find, the more secure OpenSSL will be. I hope we continue to find these kinds of problems and see them fixed. If open source has one strength, it's that when many skilled eyes DO converge on the code it can be tested and fixed far more quickly than a corporation with limited resources and only paid developers can do the same sort of debugging work. The trick is getting the eyes there in the first place.
    • by Bengie (1121981)
      OpenSSL design is fundamentally flawed. Bug fixes will probably introduce more bugs in many cases. I mean, OpenSSL will use your actual private key as a source of entropy. How messed up is that?
      • Re:This is awesome (Score:5, Informative)

        by Anonymous Coward on Thursday June 05, 2014 @11:27AM (#47172111)

        OpenSSL design is fundamentally flawed. Bug fixes will probably introduce more bugs in many cases.

        Well, the LibreSSL project is ripping out much of the code and rebuilding it: http://www.libressl.org/

        I mean, OpenSSL will use your actual private key as a source of entropy. How messed up is that?

        Ummm, your private key should be randomly generated, otherwise public key encryption doesn't work too well.

        But your private key doesn't change, so that isn't a good thing to do. Fixing the entropy is one of the many things LibreSSL is doing: http://www.openbsd.org/papers/bsdcan14-libressl/mgp00016.html

      • I mean, OpenSSL will use your actual private key as a source of entropy. How messed up is that?

        Is it messed up to add sensitive information to an entropy pool? From choice of wording it seems everyone should immediately and without reservation know better this is a stupid thing to do.

        Question is this actually a valid position or more knee jerk based on unfounded fear, ignorance of operation of an entropy pool?

        When functioning properly you shouldn't be able to extract anything except entropy from pool. It is surely possible to weaken a pool by providing known data. Likewise a pool initialized in a

        • How is it adding entropy to the pool if you keep using the same private key as one of the inputs?

        • by pipatron (966506)

          Is it messed up to add sensitive information to an entropy pool? From choice of wording it seems everyone should immediately and without reservation know better this is a stupid thing to do.

          Question is this actually a valid position or more knee jerk based on unfounded fear, ignorance of operation of an entropy pool?

          When functioning properly you shouldn't be able to extract anything except entropy from pool.

          Emphasis mine. Putting it in the pool is yet another attack vector, and a great way to increase the chance of something going wrong down the line. Either by mistake or by a planned malicious code change in parts of the code that doesn't seem to have anything to do with the private key.

        • by thogard (43403)

          Seeding the random source using a private key looks like the same concept as using your encrypted root passwords to seed the TCP sequence numbers. This is not a new concept.

    • by westlake (615356)

      it can be tested and fixed far more quickly than a corporation with limited resources and only paid developers can do the same sort of debugging work.

      Open Source does not guarantee unlimited resources. Case in point: TrueCrypt.

      Paid developers can work full time on debugging and may have a much deeper understanding of the code and how it is used.

      • by Dcnjoe60 (682885)

        it can be tested and fixed far more quickly than a corporation with limited resources and only paid developers can do the same sort of debugging work.

        Open Source does not guarantee unlimited resources. Case in point: TrueCrypt.

        Paid developers can work full time on debugging and may have a much deeper understanding of the code and how it is used.

        Wasn't the TrueCrypt announcement a form of warrant canary?

        • Noone knows. Its best to form your own opinion, and if you feel like sharing it with others, to be explicit that it is just an opinion.

          The official word is that they "got bored" according to someone who "emailed the devs".

      • The same problems that OSS has with code not being reviewed is present in closed-source models as well, such as the recent Apple security hole that managed to make it past review and stick around for quite a while. They pay developers to work on this stuff. The devs missed it. Software development is done by humans and humans commit mistakes. No source availability model can ever fully mitigate that.
      • by mcrbids (148650)

        Another case in point: OpenSSL, which had, until recently, only enough resources for 1 or 2 developers.

    • Re:This is awesome (Score:5, Insightful)

      by iamgnat (1015755) on Thursday June 05, 2014 @11:29AM (#47172133)

      open source has one strength, it's that when many skilled eyes DO converge on the code it can be tested and fixed far more quickly

      Did you even read the summary? They believe that this flaw has existed since 1998. You have a very strange definition of "quickly" if 16 years falls into that category.

      I'm all for OSS, but people like you that continue to trot out this tripe aren't helping it. The benefit isn't that there all these mythical "skilled eyes" looking at the code, it's that you can look at the code.

      • Re:This is awesome (Score:5, Insightful)

        by Jody Bruchon (3404363) on Thursday June 05, 2014 @11:43AM (#47172257)
        If you've been following OpenSSL Heartbleed coverage, you know that the project has only had one full-time developer working on it. [slashdot.org] Since Heartbleed (a recent discovery, you'll recall) they've discovered more holes to close such as this one. I'd call less than two months since more eyes started staring at OpenSSL "quickly."
      • Gp's point is once it has been found things move quickly. Tested and fixed is in the part you bolded, not found.

        You objected to a point gp did not raise.

      • And the developer that created this bug in 1998 is the same one who created heartbleed. Some people get a lifetime ban for hacking. Do we need a lifetime ban for coding?

      • by dissy (172727)

        You have a very strange definition of "quickly" if 16 years falls into that category.

        That is still a much better definition than yours appears to be!

        16 years is at least a number and a unit of time. Your argument that "Closed source bugs are found in never years" is the definition of "quickly" most everyone would call strange.

    • Re:This is awesome (Score:4, Insightful)

      by js3 (319268) on Thursday June 05, 2014 @11:41AM (#47172239)

      The more of these we find, the more secure OpenSSL will be. I hope we continue to find these kinds of problems and see them fixed. If open source has one strength, it's that when many skilled eyes DO converge on the code it can be tested and fixed far more quickly than a corporation with limited resources and only paid developers can do the same sort of debugging work. The trick is getting the eyes there in the first place.

      10 years ago someone said...

      "Opensource will eliminate all bugs, because the world can see the source". Doesn't matter if no one reads the source.

      • by g1zmo (315166) on Thursday June 05, 2014 @01:19PM (#47173189) Homepage
        Literally no one has ever said that.
      • I think that if that person knew what he was talking about, he would have said, "Open source has the potential to greatly increase the quality of code because the world can see the source and make fixes."

        Just because there's the potential for FOSS to be more reliable and more secure doesn't mean that every project will be. And even so, nothing will eliminate all bugs.

    • by jdavidb (449077)
      I suspect that in the last year since the Snowden revelations a lot more eyes have suddenly gotten focused on these packages. People are going to be looking for real security and wanting to make sure there are no secret backdoors, intentional or otherwise, in the code they depend on.
    • by jhol13 (1087781)

      I knew this excuse would used again and again, long before Heartbleed. I complained loudly (see my history) for your though to be fatally flawed.
      The problem is, that this kind of thinking generates more holes than fixes.

      But then, I think you were sarcastic and the moderators missed it.

  • ...and it was like ten Christmases to them. They're probably really down that they just lost one of their best toys.

  • by tlhIngan (30335) <slashdot AT worf DOT net> on Thursday June 05, 2014 @11:16AM (#47172025)

    This is a flaw, but it requires both ends use vulnerable OpenSSL versions. Which means your day-to-day life may or may not be affected that much.

    I mean, if you use iOS, OS X, or Windows, you're more than likely NOT using OpenSSL on the client side (except say, if you use Firefox on Windows) - since Apple and Microsoft have their own SSL implementations. If you have an Android phone or tablet, then yes, it's quite likely an issue, and while both are popular, people generally don't use them that much for data (iOS traffic, after 7 years, has finally dropped to below 50% of all mobile traffic out there, despite Android outselling iOS by a huge margin). And nevermind the oddball Linux user.

    So the real question is, how many people really ARE affected?

    Heartbleed affects everyone because it exposes server secrets irrespective of the client side. But this vulnerability is only really present if both ends use OpenSSL.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      I mean, if you use iOS, OS X, or Windows, you're more than likely NOT using OpenSSL on the client side (except say, if you use Firefox on Windows)

      Ummm, firefox uses NSS, not OpenSSL: http://en.wikipedia.org/wiki/Network_Security_Services

    • by Anrego (830717) *

      The real limiter for your average user is the requirement for man in the middle position.

      Even without this flaw, most users will just click through any warning that comes up during a man in the middle attack.

      It's still a bad thing that the mechanism designed to protect us from man in the middle is broken, but for the average user, the mechanism is already broken via apathy.

    • by Argilo (602972)
      Firefox uses NSS, not OpenSSL.
    • by Dcnjoe60 (682885)

      So the real question is, how many people really ARE affected?

      That would depend on how much, if any, of OpenSSL code was incorporated into Microsoft and Apple products regardless of the GPL. After all, 1998, was a long time ago.

    • you're more than likely NOT using OpenSSL on the client side (except say, if you use Firefox on Windows)

      That's quite the parabolic sentence there. I hope you didn't give yourself whiplash.

  • by 93 Escort Wagon (326346) on Thursday June 05, 2014 @11:30AM (#47172141)

    Given all the open-source SSL/TLS security flaws (OpenSSL, gnutls, Apple SSL) that have come out these past few months - mostly thanks to renewed interest in hunting flaws, thanks to the Snowden revelations, I suspect - I hope that companies like Microsoft are also seeing this as a wake-up call driving them to do code reviews on their closed-source SSL/TLS code.

  • That's not an insignificant set of conditions that must be present for a successful attack

    But it is exactly the point of TLS, to protect against such an attacker. If you know you don't have a man-in-the-middle then you don't even need it in the first place.

    True that the server might not be running that version, but a non-trivial number of them are.

  • After reading the advisory from OpenSSL, I'm still confused by what is vulnerable and what isn't. The flaw requires both the client and server to be vulnerable. If the client is using OpenSSL, they're vulnerable for 0.9.8/1.0.0/1.0.1. But if the server is using OpenSSL, they're only vulnerable if using 1.0.1/1.0.2(beta). Yet the bullet list of recommendations points out that servers should upgrade even if they're using 0.9.8: * OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za
  • I see a lot of comments that try to convince that "closed source isn't any better". So my actual question is: would it be some kind of sin if closed source was actually better?
    • by cmburns69 (169686)

      The accusation implied in that response is that "open source must be weak because vulnerabilities are found".

      Whether or not closed source is better is largely irrelevant. Whichever fulfills your needs the best (be they verifiable security, price, etc) is what is "better" for you.

  • at least my install still uses 0.9.8n though who knows what other nasties lurk in that one

  • Something does not add up. How is there a new vulnerability that's been in the source for sixteen years? How are older versions of the server code not vulnerable if it's sixteen years old?

  • Is OpenVPN affected?

Suburbia is where the developer bulldozes out the trees, then names the streets after them. -- Bill Vaughn

Working...