1. 54
  1.  

  2. 10

    I think it’s important to stress that this bug allows reading memory of the process that is doing SSL and the memory disclosure is not limited to SSL private keys. Some of the discussion is focusing so much on an attacker stealing your SSL key and being able to decrypt encrypted traffic that was gained via MITM, which makes it seem kind of far-fetched.

    This bug is disclosing plaintext memory buffers of your web server daemon, which likely contain recent HTTP requests with headers/cookies, your internal PHP code, or anything else the web server has to read. An attacker doesn’t have to bother MITMing your server and recording SSL traffic for offline analysis with your carefully extracted private SSL key. They can just issue a few requests and dump a bunch of HTTP headers which include the cookie your browser just sent to your website, effectively allowing the attacker to login as you, without any MITM attack.

    I just tried a test tool against a few public websites that I login to every day and for two of them, it dumped complete HTTP headers of other peoples' requests, including their session cookies and form data.

    Even if your own servers are patched, you can easily get your account compromised if you login to servers that aren’t patched. Here’s an example from Yahoo’s mail servers: https://twitter.com/markloman/status/453502888447586304

    1. 6

      I ran a test (which I’m in the process of writing up) in which I specifically attempted to extract key material from a site where I knew the private key; in dumping 128M across over 7k connections, I wasn’t able to extract any. However, I was consistently able to recover all HTTP headers. In fact, I think those headers are present in every memory dump I was able to get.

      1. 1

        Which OS is the server running?

        1. 1

          Ubuntu 12.04, LTS chosen because it’s the base we use in production.

      2. 1

        Agreed. Having played with it and now reading the reports from some other people, it seems recovering the private key was a red herring. Unfortunately, the freakout over that is obscuring what’s likely to be a bigger problem that affects more people. Yahoo (e.g., and everybody else) is going to recycle their certs, even though it’s not necessary, but how many sites are going to flush their session cache? “Don’t login to your bank today” would have been far more useful advice than “Figure out how to revoke all your SSL certs.”

        On the bright side, maybe some more people will realize that CRLs are useless.

      3. 5

        If there was still anyone thinking forward secrecy was a waste of time, this should convert them.

        1. 4

          This is really bad.

          The commit with the fix

          It doesn’t look like most distros have had time to package and push updates yet. :-/

            1. 3

              For Arch: core still uses the last vulnerable release. The patched release is in testing.

              https://www.archlinux.org/packages/core/x86_64/openssl/

              1. 2

                Newest version is now in Arch core.

              2. 3

                For what it’s worth, these are all patched now.

                1. 2

                  CentOS had also released a workaround package while waiting for the upstream fix from Red Hat:

              3. 2

                opensuse has an update out now, but it took a while. running “online update” in yast pulls it, otherwise i guess it will come through the regular updater in the next few hours (assuming you have it running).

              4. 4

                What is the policy in lobste.rs about ars posts? For the most part they are entirely derivative and of poor quality, IMO. On top of that, this story has been posted here multiple times already, including the actual commit that fixes it, I don’t think there is much reason to post a laymans addition.

                My 2 cents.

                1. 1

                  A PoC is now out for testing vulnerable clients.