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.