Nope. It only requires being able to read neighboring cells. It would make a privilege escalation attack harder but not impossible. DoS attacks would still be relatively easy.
Wouldn't this be hard to exploit from an attackers poitn of view? I mean there is no way to know what data was currently in RAM, it is at best a blind attack.
That depends on what you mean by "break into". If you mean sample data (read) from the control plane or other VMs, then yes; however, the attacker may have difficulty targeting which data is read. The attacker would not be able to write to that memory or gain any sort of execution privilege using this method alone.
Why do you believe this would help? Have you seen the attack from the BlackHat?[1] It doesn't require being able to read any plain text and it doesn't matter how the data is stored, only that it's near. You don't even have to have any access to the target memory or even know where it is, only the ability to cause something else to read it predictably.
The memory encryption features are a solution to very specific problems.
If the CPU is able to access the memory, then any exploit that gains the execution context of the legitimate user can also access the memory.
If it doesn't, the normal memory access control should be enough.
I'm iffy on how well they protect against the various side channels.
Mostly because I haven't looked far enough into it.
IME it protects against cold boot attacks, a theoretic attack of a logic analyzer on the memory bus, and potentially to some degree unbounded reads. But the latter only with very limited gadgets.
I don't really understand the threat model in which this provides a real security benefit. If someone can inspect the contents of memory, can't they also recover the encryption key somehow?
It's not so much about sensitive info residing in the kernel, but that the kernel has an identity mapping of the entire physical memory, Thus if you can read kernel memory, you can dump all ram, where secrets from other processes or virtual guests reside.
I don't know if Minix or Hurd maps all of ram into the kernel address space though (or if they add the kernel address space to each user space processes , as the exploit also requires)
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.
I believe the point here is this: now that the hacker community knows about these opcodes, they can now focus on other ways to access the functionality.
Yes, you currently need Intel equipment to access this functionality today, but its quite probable that some innocuous function on the CPU itself can be used to gain access.
I mean who would have thought just reading and writing memory you already have access to could be used to exfiltrate system secrets? (Riwhammer)
The article briefly mentions the possibility to access secrets on a hardware level by monitoring the ressources of other threads. I have no idea if this is only possible in theory but completely impractical becauste it takes so much effort. Have there been attacks like that in the past?
The processor maybe, but what about the e.g. USB3 controller, WIFI, etc, that can also freely snoop around your memory. Are there even open USB3 implementations?
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?
reply