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

From: "Doron Fediuck" <dfediuck(a)redhat.com&gt; To: "Dan Kenigsberg" <danken(a)redhat.com&gt; Cc: users(a)ovirt.org Sent: Friday, June 13, 2014 2:14:30 PM Subject: Re: [ovirt-users] KSM and cross-vm attack ----- Original Message ----- > 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. Indeed we had an old bz for it. A brand new ovirt RFE will help. Also, it is possible to disable ksm for a cluster today. So it's already possible to have an optimized cluster and a more strict one in the same DC.