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.
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.
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 :(
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 :))
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.
So if your key was at an address less than x the bug would never read it, was my point. So I guess that means you'd have to force the UDP datagram payload to be stored high as that dictates what x is?
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!
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.
http://blog.cloudflare.com/answering-the-critical-question-c...
Matthew Prince Co-founder & CEO, CloudFlare