On Fri, Jun 13, 2014 at 11:05:37AM +0200, Jorick Astrego wrote:
Hi Sven,
Thanks for you response, I will read some more.
But as you say it has been known for a while and I was aware of it for many years although never diving into the specifics. I always thought it was not a practical attack vector
What caught my attention was that it was so fast it can be done in less then a minute:
Lightning-Fast Attack: *Even in the worst case scenario (cross-VM) the attack** **succeeds in less than a minute. To the best of our knowledge, no faster attack** **has been implemented against AES in a realistic cloud-like setting. This also** **means that just one minute of co-location with the encryption server suffices to** **recover the key.*
For the most parts, it's easier to hack you machine directly or social-engineer your way into it, than it is to hack/get access to a different vm on the same system and than hack another vm.
So that was the part that worries me, if I have a public cloud offering and someone doesn't hack a vm but simply rents one. He can then spawn a new VM every couple of minutes and it will probably be on a different host each time..... with different neighbours.
You could hack every vulnerable customer VM in a couple of hours this way and it would all be undetected.
There are also still no automatic tools for this, which I'm aware of (if they are, I'd like to be pointed to them).
As soon as automatic attack tools will cover this scenario I'm pretty sure we'll see an increase in hacked vms and sniffed private keys. I'm sure there are automatic tools being built as we speak but they will not be generally available.
It would be relatively simple to disable KSM per VM. This way, a customer that values security more than density, could pay more to keep his memory pages unscanned by KSM. Anyone cares to open an RFE for that? I remember that the idea was discussed, but I do not find a formal bug that tracks this.