4 ms·

You can read more about the CloudFlare Challenge and our own tests on obtaining SSL Private Key material here: http://blog.cloudflare.com/answering-the-critica

You can read more about the CloudFlare Challenge and our own tests on obtaining SSL Private Key material here: http://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed http://blog.cloudflare.com/answering-the-critical-question-c... Matthew Prince Co-founder & CEO, CloudFlare

conformal 13y ago
nice write up. we saw similar results in that the keying material never made it into the memory leaked. i've never felt so thankful for a memory allocation pattern.
deleted 13y ago
[deleted]
- ditoax 13y ago
  The don't sign comments rule is designed to stop pointless posting of company URLs when there is no need to. In this case it is clearly appropriate for Matthew to disclose who he is as it is important to the context of the post.
ominous_prime 13y ago
Thanks. This makes a lot of sense, and matches what I saw myself. I never got anything out of nginx, but I found apache quite easy. I never built more than a POC, and left it at that. I didn't think about it at the time, but it was only on a newly started apache instance. Coupled with the fact the apache as a frontend tls server is pretty rare on big sites nowadays, I'm feeling pretty good about what did happen, vs what could have happened.
apaprocki 13y ago
It seems like a "feature" that you'd want your process to store the private key material as low as possible in the address space so that arbitrary read overruns don't run the risk of hitting it. It seems to just accidentally be this way in nginx, but I wonder if it should just be another (tiny) layer in the overall security design.
- pbhjpbhj 13y ago
  Shouldn't they be at the top of the address space then overruns would never hit them as they'd start below or does it not work like that.
  - justincormack 13y ago
    Or you can put in a memory area with unmapped sections on both sides if you are paranoid.
    - apaprocki 13y ago
      True.. I wonder if any specs/certifications actually require something like that. Typically I mostly use tricks like that to track down bugs, but there's nothing wrong with using it in production for something like a single key/cert alloc. It becomes a bit unwieldy if you have lots of things to protect. (Especially on machines with 64k pages :))
      - justincormack 13y ago
        Well it seems like Akamai were doing exactly that. If you have lots I would go multi process though. Someone else who uses Powerpc?
    - Shish2k 13y ago
      IIRC openbsd's malloc does something like that by default, so every bit of data gets its own protected address space... and then the openssl guys built their own malloc without that feature, to get better performance :(
  - apaprocki 13y ago
    The bug is reading 64k from x -> x+64k. You'd want the key as low as possible in memory so the chance of the heap implementation allocating a request below it (thus allowing the +64k to overlap into the key) is next to nil.
    - 13y ago
danielweber 13y ago
What is the format of the private key? I.e., is it a 8192-bit AES256 key?
- quasque 13y ago
  It's using RSA with key length of 2048 bits [1], and one can assume that both prime factors have equal bit length [2] i.e. 1024 bits each, and so the size of all the other private components can be derived from that. I don't know what OpenSSL's in-memory format is for this data, I suppose therein lies a good part of the challenge! [1] https://www.ssllabs.com/ssltest/analyze.html?d=cloudflarechallenge.com https://www.ssllabs.com/ssltest/analyze.html?d=cloudflarecha... [2] https://github.com/openssl/openssl/blob/master/crypto/rsa/rsa_gen.c#L227-228 https://github.com/openssl/openssl/blob/master/crypto/rsa/rs...
dimsumdumdum 13y ago
Grandstand much?

conformal 13y ago

nice write up. we saw similar results in that the keying material never made it into the memory leaked. i've never felt so thankful for a memory allocation pattern.

deleted 13y ago

[deleted]

ditoax 13y ago
The don't sign comments rule is designed to stop pointless posting of company URLs when there is no need to. In this case it is clearly appropriate for Matthew to disclose who he is as it is important to the context of the post.

ominous_prime 13y ago

Thanks. This makes a lot of sense, and matches what I saw myself. I never got anything out of nginx, but I found apache quite easy. I never built more than a POC, and left it at that. I didn't think about it at the time, but it was only on a newly started apache instance. Coupled with the fact the apache as a frontend tls server is pretty rare on big sites nowadays, I'm feeling pretty good about what did happen, vs what could have happened.

apaprocki 13y ago

It seems like a "feature" that you'd want your process to store the private key material as low as possible in the address space so that arbitrary read overruns don't run the risk of hitting it. It seems to just accidentally be this way in nginx, but I wonder if it should just be another (tiny) layer in the overall security design.

pbhjpbhj 13y ago
Shouldn't they be at the top of the address space then overruns would never hit them as they'd start below or does it not work like that.
- justincormack 13y ago
  Or you can put in a memory area with unmapped sections on both sides if you are paranoid.
  - apaprocki 13y ago
    True.. I wonder if any specs/certifications actually require something like that. Typically I mostly use tricks like that to track down bugs, but there's nothing wrong with using it in production for something like a single key/cert alloc. It becomes a bit unwieldy if you have lots of things to protect. (Especially on machines with 64k pages :))
    - justincormack 13y ago
      Well it seems like Akamai were doing exactly that. If you have lots I would go multi process though. Someone else who uses Powerpc?
  - Shish2k 13y ago
    IIRC openbsd's malloc does something like that by default, so every bit of data gets its own protected address space... and then the openssl guys built their own malloc without that feature, to get better performance :(
- apaprocki 13y ago
  The bug is reading 64k from x -> x+64k. You'd want the key as low as possible in memory so the chance of the heap implementation allocating a request below it (thus allowing the +64k to overlap into the key) is next to nil.
  - 13y ago

danielweber 13y ago

What is the format of the private key? I.e., is it a 8192-bit AES256 key?

quasque 13y ago
It's using RSA with key length of 2048 bits [1], and one can assume that both prime factors have equal bit length [2] i.e. 1024 bits each, and so the size of all the other private components can be derived from that. I don't know what OpenSSL's in-memory format is for this data, I suppose therein lies a good part of the challenge! [1] https://www.ssllabs.com/ssltest/analyze.html?d=cloudflarechallenge.com https://www.ssllabs.com/ssltest/analyze.html?d=cloudflarecha... [2] https://github.com/openssl/openssl/blob/master/crypto/rsa/rsa_gen.c#L227-228 https://github.com/openssl/openssl/blob/master/crypto/rsa/rs...

dimsumdumdum 13y ago

Grandstand much?