Private keys may be inaccessible to Heartbleed

Private keys may be inaccessible to Heartbleed

Summary: [UPDATED] Research by CloudFlare indicates that Heartbleed can be used to obtain contents of server memory, but not private keys.

SHARE:
TOPICS: Security
6

[UPDATE: Well that didn't take long. Two people have been successful at the CloudFlare challenge and have captured the private keys. Cloudflare says that they restarted the servre in the middle and perhaps that contributed, but even so it seems their analysis was wrong.] 

Internet software and services firm CloudFlare has published research findings which indicate that the worst-case scenario for Heartbleed may not be possible.

Heartbleed is a bug in OpenSSL which can be used to obtain up to a 64KB block of memory belonging to the server and whose contents are unspecified. The worst-case scenario in this week's speculation has been that an attacker could use it to obtain the server's certificate and private keys, which would enable the attacker to decrypt the communications of others with the server.

CloudFlare's research indicates that the server's private keys are highly unlikely to be at a point in memory where a Heartbleed attack would reach them. In the tests they performed on the custom version of the NGINX server they use for their own CDN and other services they were not able to obtain a single private key after extensive testing of gigabytes of data. They speculate that Apache servers may be vulnerable for a very brief period at boot time, but web servers don't boot all that often and the timing would not be under the control of the attacker.

The specific reasons why the keys are likely to be inaccessible are complicated and explained well in the CloudFlare blog, but briefly the reasons are that the certificates and Heartbleed data are both stored on the heap, which grows up in memory, and the certificates are loaded early in the server startup. Heartbleed requests are likely to come in after this point and load in memory above the keys and certificates.

If it is true that private keys are not vulnerable, at least as a practical matter, then some of the worst of the implications for Heartbleed are no longer in force. The main one is the need for sites to revoke old certificates and reissue new ones. This is a process which is moving very slowly (see new Netcraft report), and the Public Key Infrastructure is not designed to handle a mass revoke and reissue, an event which would impose a significant performance burden on the Internet.

CloudFlare is careful not to claim that their findings are final or that they prove that keys are inaccessible. In order to further the research they have created a "CloudFlare Challenge" site running a vulnerable web server and ask the public to attack it and try to steal the keys.

Hat tip to Bruce Schneier.

Topic: Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

6 comments
Log in or register to join the discussion
  • good on them...

    sounds reasonable that private keys would not be easily accessible.
    but the old 'i only have to succeed once, you have to protect all the time' issue is in play.

    good on CloudFlare for setting up the challenge site.
    BitBanger_USA
  • I believe the 'never'

    Based on how they describe it, and their description makes sense, it also makes sense that you'll never get at the keys with Heartbleed. It's possible that you could for a very brief period on Apache, but as a practical matter it's not worth attacking for that.
    They can't say "never" because it's impossible to prove the non-existence of such an effect, but 'never' makes sense.
    With the key loss gone, Heartbleed is a bad information disclosure vulnerability, but hardly of the unprecedented nature we've been hearing.
    larry@...
    • Uncle

      As I've already posted, the challenge has been met. I'm surprised at this, but there it is.
      larry@...
  • Seems logical

    Having in mind the effects of the "sequenced overdecoration" of the flaw.

    Yes programmers have tendencies to "make artwork" addendum’s in source code.
    Are often unaware of the consequences, and frequently don't know how
    the compilers switchsets/optimizers work.

    Understand that as programming puts you up in a special mindset/mode.
    Experienced this effect personally.

    So lets work together to make things better, instead of making public scares
    among computer users that don't have the faintest idea of what they
    do while surfing N clouding, "socializing" with some 95 % of their
    total human communication abilities disabled, e.t.c.
    X15meshman
    • https://www.cloudflarechallenge.com/heartbleed

      Two times access to private key

      Now it's solidly confirmed thank's to Cloudflare .
      X15meshman
  • Most likely is the fact that private keys are loaded once...

    and never returned to the allocation pool for buffer re-use.

    Now once something is returned to the pool it would get reused - and any query could then get things in that buffer (and any following buffer(s))... The private keys are constantly being used - AND have to be loaded BEFORE any queries can be responded to would seem to make it unlikely if not impossible to retrieve the private key.

    I can't think of any reason the private key would be returned to the pool... or even need to be reloaded.
    jessepollard