One question - this keeps talking about attackers being able to "read all of memory." Does anyone know whether that's limited to the process that is running OpenSSL code?
Well, I don't think it's anything in memory, but whatever was up to 64k from wherever the downloaded packet was put in userspace (Edit: Er, 64k at a time, but the attacker can try again over and over). Since the kernel should be handing only zeroed pages to userspace to use as a buffer then it should only be memory used by the process using openssl at risk.
The big problem is that this is still a gigantic range of processes (and possible memory buffer contents). But SSH at least would appear to be fine, unless you've ever transferred an SSH key over TLS using OpenSSL.
Is such an attack really possible on a real system with real workloads running something in addition to an OpenSSL implementation processing keys and the attack code?
No this was written about a couple days ago. It frees the memory and because Open uses a LIFO memory allocater it can "safely" assume that whatever was still in there is still in there. I belive that in order to exploit this you would need to exhaust its internal allocator (so that it requests more from the OS) and your payoff would be... having your connection dropped.
This was discovered in the course of someone's attempt to figure out why OpenSSL randomly drops connections when its using a sane/OS supplied allocator.
Imagine the memory on their server is encrypted with an on-processor key (something like intel SGX) -- reading OS memory, e.g dumping from linux or hardware, you can't read it unless you somehow extract the key (which are different on each chip) from the physical chip. Now, the process running using that encrypted memory generates TLS keys for you to send the data, and operates on it only inside this secure enclave.
There is no way to access it without destroying the chip, and even in this scenario it will be extremely expensive and imo unlikely, certainly impossible at scale. Some scientists may be able to do it once in a lab.
But you need to exhaust the memory space, especially in the variants that cross VM boundaries. You can’t just go and read the few hundred bytes that contain the neighbors private TLS keys. So if you can force the attacker to read memory at a tenths of the current rate, chances of a successful attack might be severely diminished.
This seems like a good idea, I'm curious what OpenSSL or other crypto libraries do to keep secrets from being paged out to disk by the virtual memory machine? That seems like a legitimate attack vector.
Someone with more knowledge please correct me if this is inaccurate, but from what I have been able to understand this basically exposed 16kb of random memory each heartbeat? So the fear would be that a persistent attacker I guess could continuously run this and scan the output trying to match things like security certificates?
While I am sure this could be used on high value targets with enough resources, as a small web service outside of the tech industry I feel pretty confident that no one would invest those kind of resources to steal our SSL cert. Is that misguided?
The scope of the potential damage is rather huge and can't really be overstated.
It's akin to handing over your entire working OS memory to a person, complete with all encryption keys, session tokens and whatever documents you're working on.
Potentially, anyway. The working proof-of-concept attacks I've seen use a lot of CPU to read memory and they read slowly, but those are proof-of-concepts and it would not be terribly difficult for a motivated person to make them significantly faster and less obvious.
That's my question as well. I'm not a security expert, but this doesn't seem all that concerning for anything other then the highest security applications. It seems to me that executing this attack not only requires running code on the target machine (which admittedly isn't that big of a hurdle), but requires basically complete knowledge of memory allocation at the time of the attack, something that is fairly opaque and ever changing on most hardware.
Is there something I'm missing here? What are the realistic attacks that this vulnerability allows?
They say they can reliably read memory around 120kB/s with one vulnerability and 1kB/s with the other. It just works, all the time. Some of the PoC takes a few minutes to initialize.
Wait, KeePass only decrypts the database into memory for a particular process, right? So it would take an exploit of some kind to read the memory holding the decrypted database?
An attack that reads everything is different from an attack that writes everything; 4.1 doesn't seem to understand that. The latter will just crash the computer like some kind of Core Wars champ. The former can copy out the whole heap! So a writing attacker has to worry about crashing the server or getting caught. A reading attacker can just loop, then run.
The guard pages I believe help---but random guard pages just mean I won't know quite what's protected and what is not. This last week I benefitted quite a bit from being able to reconstruct year old server memory layouts precisely.
In this case, I want a marginal chance of compromise no worse than 2^-192, about the strength of RSA-2048.
reply