[ovirt-users] KSM and cross-vm attack

[Doron Fediuck]

----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: users at 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 at redhat.com>
> > To: "Jorick Astrego" <j.astrego at netbulae.eu>, alitke at redhat.com,
> > doron at redhat.com
> > Cc: users at 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.

One more thing;

For future reference, please us the procedures details here: http://www.ovirt.org/Security
For anything which may impact other users as well.

Thanks,
Doron