Announcement

Collapse
No announcement yet.

The OpenSSL Heartbleed Bug Strikes The Internet

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • The OpenSSL Heartbleed Bug Strikes The Internet

    Phoronix: The OpenSSL Heartbleed Bug Strikes The Internet

    As many Phoronix readers have already reported in, a very serious OpenSSL security vulnerability was discovered that allows for attackers to read memory in 64k memory chunks. A very serious bug in OpenSSL 1.0.1/1.0.2-beta is leaking information since the bug's introduction in 2011...

    http://www.phoronix.com/vr.php?view=MTY1ODE

  • #2
    A lot of fanboys told us to use OpenSSL when a vulnerability in GnuTLS was found. I hope this shut them up. Software is never perfect.

    Comment


    • #3
      Regardless of what happened in the GnuTLS thread, this is bad news. I've already updated my work machine, but this is going to impact a lot of businesses/sites/certificates and also users. I suspect I'm in for another round of full password changes.

      Comment


      • #4
        Updates which address this security vulnerability are now available in the Ubuntu repositories for all supported versions of Ubuntu.

        Comment


        • #5
          Originally posted by madbiologist View Post
          Updates which address this security vulnerability are now available in the Ubuntu repositories for all supported versions of Ubuntu.
          people said ubuntu delivered the patch and indeed last night my mint 16 installation received an openssl update. however when i type: openssl version -a . I get


          OpenSSL 1.0.1e 11 Feb 2013
          built on: Mon Apr 7 20:33:19 UTC 2014
          platform: debian-amd64

          ^

          My laptop is also running mint 14 and gets

          something similar but the version is 1.0.1c

          Im getting the feeling that 1.0.1g is the patched version ?

          So I tried manually adding the g version but the make file didn't work properly. Is there a PPA for this to get the latest version ?

          Thanks

          Comment


          • #6
            Originally posted by phill1978 View Post
            OpenSSL 1.0.1e 11 Feb 2013
            built on: Mon Apr 7 20:33:19 UTC 2014
            {...}
            something similar but the version is 1.0.1c
            {...}
            Im getting the feeling that 1.0.1g is the patched version ?
            - 1.0.1g is the official OpenSSL version which doesn't have the vulnerability.

            What Debian, Ubuntu, Mint, and many other distribution are providing you, is an update of openssl, still the exact same version as before (so no change from whatever was there before to 1.0.1g, and thus no incompatibility problems due to changing versions) but with a patch against "heartbleed" applied in.

            Hence the version string you're getting: this 1.0.1e version was compiled just a few hours ago, with probably the patch applied.
            (More information, see the Security Update page from your distribution. For example for Debian and openSUSE. I'm sure your Ubuntu and Mint should have similar sources of information.)

            Comment


            • #7
              Originally posted by DrYak View Post
              - 1.0.1g is the official OpenSSL version which doesn't have the vulnerability.

              What Debian, Ubuntu, Mint, and many other distribution are providing you, is an update of openssl, still the exact same version as before (so no change from whatever was there before to 1.0.1g, and thus no incompatibility problems due to changing versions) but with a patch against "heartbleed" applied in.

              Hence the version string you're getting: this 1.0.1e version was compiled just a few hours ago, with probably the patch applied.
              (More information, see the Security Update page from your distribution. For example for Debian and openSUSE. I'm sure your Ubuntu and Mint should have similar sources of information.)
              thanks for the reply

              Comment


              • #8
                Joke's on you, I'm still on 0.9.8. Ha!

                Comment


                • #9
                  Originally posted by curaga View Post
                  Joke's on you, I'm still on 0.9.8. Ha!
                  But not the services you were using, so...

                  Comment


                  • #10
                    Originally posted by phill1978 View Post
                    people said ubuntu delivered the patch and indeed last night my mint 16 installation received an openssl update. however when i type: openssl version -a . I get


                    OpenSSL 1.0.1e 11 Feb 2013
                    built on: Mon Apr 7 20:33:19 UTC 2014
                    platform: debian-amd64

                    ^

                    My laptop is also running mint 14 and gets

                    something similar but the version is 1.0.1c

                    Im getting the feeling that 1.0.1g is the patched version ?

                    So I tried manually adding the g version but the make file didn't work properly. Is there a PPA for this to get the latest version ?

                    Thanks
                    There is also a workaround for the affected versions. Recompile with "-DOPENSSL_NO_HEARTBEATS" as a compile time option. It's possible that the Ubuntu patched version just recompiled with that feature disabled (which is what redhat/centos have done with version 1.0.1e)

                    Comment


                    • #11
                      I just patched all our production RHEL servers today. The fixed version is still version 1.0.1e on RHEL6. Red Hat implemented a fix and did not increment the OpenSSL version number.

                      RHSA-2014:0376-1

                      https://rhn.redhat.com/errata/RHSA-2014-0376.html
                      Last edited by torsionbar28; 04-09-2014, 04:42 PM.

                      Comment


                      • #12
                        I'm not being paranoid or anything... But I consider this as a not so honest mistake. NSA probably have found a better exploit than heartbleed and we're all none the wiser.
                        Originally posted by xeekei View Post
                        A lot of fanboys told us to use OpenSSL when a vulnerability in GnuTLS was found. I hope this shut them up. Software is never perfect.
                        Totally agree.

                        Comment


                        • #13
                          Originally posted by Veerappan View Post
                          There is also a workaround for the affected versions. Recompile with "-DOPENSSL_NO_HEARTBEATS" as a compile time option. It's possible that the Ubuntu patched version just recompiled with that feature disabled (which is what redhat/centos have done with version 1.0.1e)
                          And indeed the Heartbeat extension looks completely stupid and useless to begin with.
                          - There are other ways to keepalive a running SSL/TLS connection. Heartbeat doesn't bring anything new.
                          - If someone *REALLY* needs a custom payload in a heartbeat, they should have gone for a fixed size (a 64bit or 128bit number, for example). That would have been much more efficient and still customisable enough (could hold a 128bits GUID, for example).
                          - If someone *REALLY* needs a variable size payload, the extra length parameters is redundant (and is really begging for such mistake to happen). It would have been much more simpler to consider the payload like "up to the end of the current packet".

                          Originally posted by b15hop View Post
                          I'm not being paranoid or anything... But I consider this as a not so honest mistake. NSA probably have found a better exploit than heartbleed and we're all none the wiser.
                          I would consider that *the programmer* probably made a honnest mistake. In fact the standard is practically calling for one to happen.
                          (At least in any package that relies on simple C-pointer-manipulation and standard C-library function, like OpenSSL. Of course if one uses another technique which does bound checking, such as C++...)
                          This error is typical, and saddly automatic checking tools didn't pick that specific instance. (Luckily, since then they got better)

                          I find the standard *very suspicious*. As pointed above, I don't really see what problem they want to solve with heartbeats, and they way the standard was written is stupid and practically calling for this problem.
                          Given that the NSA is known to influence standards (as per Snowden), it might have been their plan all along.

                          Originally posted by xeekei View Post
                          A lot of fanboys told us to use OpenSSL when a vulnerability in GnuTLS was found. I hope this shut them up. Software is never perfect.
                          And both OpenSSL and GnuTLS are pretty fine, as is also mozilla's NSS: They are all very widely used libraries, meaning that they get enough attention and bugs are eventually discovered and patched (as was the case with openssl. think about what monstrosities are lurking inside microsoft windows. nobody could pratically know. I mean nobody outside NSA).

                          But it would be good if:
                          - automatic testing tools got better at spotting such problems (and some got worked on)
                          - security critical things like crypto could rely on bases a little bit more secure (use bound-checking library instead of direct pointer manipulation).

                          Comment


                          • #14
                            Originally posted by DrYak View Post
                            And indeed the Heartbeat extension looks completely stupid and useless to begin with.
                            - There are other ways to keepalive a running SSL/TLS connection. Heartbeat doesn't bring anything new.
                            - If someone *REALLY* needs a custom payload in a heartbeat, they should have gone for a fixed size (a 64bit or 128bit number, for example). That would have been much more efficient and still customisable enough (could hold a 128bits GUID, for example).
                            - If someone *REALLY* needs a variable size payload, the extra length parameters is redundant (and is really begging for such mistake to happen). It would have been much more simpler to consider the payload like "up to the end of the current packet".



                            I would consider that *the programmer* probably made a honnest mistake. In fact the standard is practically calling for one to happen.
                            (At least in any package that relies on simple C-pointer-manipulation and standard C-library function, like OpenSSL. Of course if one uses another technique which does bound checking, such as C++...)
                            This error is typical, and saddly automatic checking tools didn't pick that specific instance. (Luckily, since then they got better)

                            I find the standard *very suspicious*. As pointed above, I don't really see what problem they want to solve with heartbeats, and they way the standard was written is stupid and practically calling for this problem.
                            Given that the NSA is known to influence standards (as per Snowden), it might have been their plan all along.



                            And both OpenSSL and GnuTLS are pretty fine, as is also mozilla's NSS: They are all very widely used libraries, meaning that they get enough attention and bugs are eventually discovered and patched (as was the case with openssl. think about what monstrosities are lurking inside microsoft windows. nobody could pratically know. I mean nobody outside NSA).

                            But it would be good if:
                            - automatic testing tools got better at spotting such problems (and some got worked on)
                            - security critical things like crypto could rely on bases a little bit more secure (use bound-checking library instead of direct pointer manipulation).
                            Writing standards is almost like writing their own rules. If they influence the rules enough, then it allows them free reign because it's their rules to begin with. Almost like the law supersedes the code. The problem is, if the software has holes everywhere due to poor standards, it's not just NSA that will take advantage of loopholes. Ie the public is then no longer protected from anyone who takes advantage of such holes.

                            Also if the programmer honestly didn't intend to leave the hole, yet the policy creates the opportunity for more mistakes, then the programmer gets the blame and the real cause is the policy. A seemingly sly way to hide from such accusations. Maybe a policy update is in order.

                            Comment


                            • #15
                              Originally posted by b15hop View Post
                              Also if the programmer honestly didn't intend to leave the hole, yet the policy creates the opportunity for more mistakes, then the programmer gets the blame and the real cause is the policy. A seemingly sly way to hide from such accusations. Maybe a policy update is in order.
                              If you're writing code that's supposed to be secure and robust, you don't trust external data.

                              Ever.

                              The spec looks crazy, but any programmer working on this kind of code should know to sanitize incoming data before using it.

                              Comment

                              Working...
                              X