Re: [ovirt-users] KSM and cross-vm attack

From: "Dan Kenigsberg" <danken(a)redhat.com&gt; To: "Jorick Astrego" <j.astrego(a)netbulae.eu&gt;, alitke(a)redhat.com, doron(a)redhat.com Cc: users(a)ovirt.org Sent: Friday, June 13, 2014 1:36:17 PM Subject: Re: [ovirt-users] KSM and cross-vm attack 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.