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

2014-06-13 Thread Sven Kieske
Hi,

it's kind of you to let those know
about these attacks who do not already know them, but
this should be well understood by every professional by know.

Shared resources are never secure, if you
can not control the access from third parties
to shared memory.

this does not just affect KSM (or similar
techniques from vmware, xen and microsoft)
but also L3-Caches of modern CPUs.

If you are interested in these topics, here are some papers:

L3-Side-Channel attack to recover private
GPG-Keys from another VM:

http://eprint.iacr.org/2013/448.pdf

Correlation attack against openssl,
polarssl and libgcrypt on xen and vmware:

https://eprint.iacr.org/2014/248.pdf

I don't know if IBMs PowerVM is vulnerable to such
attacks, as it's LPAR architecture is certified
EAL 4+ (which might not tell anything about this attack
vector).

But you always need to have in mind, what attack
scenario you talk about:

These attacks are about a malicious vm (this could be a
hacked/hijacked vm) which recovers parts of the shared memory
from a known other instance to attack.

if you have high security concerns you might want _not_
to share your physical server with third party controlled
vms, or with vms which might be the target of getting hacked
(or which runs software, which is known to be vulnerable).

I still consider this scenario not as that relevant today, as
there are many more low hanging fruits (sadly).

This means in short:

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.

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.


HTH

-- 
Mit freundlichen Grüßen / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH  Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


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

2014-06-13 Thread Jorick Astrego

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.



Kind regards,

Jorick Astrego
Netbulae B.V.



On 06/13/2014 09:38 AM, Sven Kieske wrote:

Hi,

it's kind of you to let those know
about these attacks who do not already know them, but
this should be well understood by every professional by know.

Shared resources are never secure, if you
can not control the access from third parties
to shared memory.

this does not just affect KSM (or similar
techniques from vmware, xen and microsoft)
but also L3-Caches of modern CPUs.

If you are interested in these topics, here are some papers:

L3-Side-Channel attack to recover private
GPG-Keys from another VM:

http://eprint.iacr.org/2013/448.pdf

Correlation attack against openssl,
polarssl and libgcrypt on xen and vmware:

https://eprint.iacr.org/2014/248.pdf

I don't know if IBMs PowerVM is vulnerable to such
attacks, as it's LPAR architecture is certified
EAL 4+ (which might not tell anything about this attack
vector).

But you always need to have in mind, what attack
scenario you talk about:

These attacks are about a malicious vm (this could be a
hacked/hijacked vm) which recovers parts of the shared memory
from a known other instance to attack.

if you have high security concerns you might want _not_
to share your physical server with third party controlled
vms, or with vms which might be the target of getting hacked
(or which runs software, which is known to be vulnerable).

I still consider this scenario not as that relevant today, as
there are many more low hanging fruits (sadly).

This means in short:

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.

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.


HTH



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


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

2014-06-13 Thread Dan Kenigsberg
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.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


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

2014-06-13 Thread Doron Fediuck


- Original Message -
 From: Dan Kenigsberg dan...@redhat.com
 To: Jorick Astrego j.astr...@netbulae.eu, ali...@redhat.com, 
 do...@redhat.com
 Cc: users@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.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


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

2014-06-13 Thread Doron Fediuck


- Original Message -
 From: Doron Fediuck dfedi...@redhat.com
 To: Dan Kenigsberg dan...@redhat.com
 Cc: users@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 dan...@redhat.com
  To: Jorick Astrego j.astr...@netbulae.eu, ali...@redhat.com,
  do...@redhat.com
  Cc: users@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
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


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

2014-06-13 Thread Sven Kieske
Done that:
https://bugzilla.redhat.com/show_bug.cgi?id=1109157

Am 13.06.2014 12:36, schrieb Dan Kenigsberg:
 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.

-- 
Mit freundlichen Grüßen / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH  Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


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

2014-06-13 Thread Sven Kieske
This site misses public keys for sending encrypted mails.

That's not that good for a security related mail.

I'm sure it just isn't mentioned in the wiki, could one
use the same keys as for redhat security mailings?

Am 13.06.2014 13:16, schrieb Doron Fediuck:
 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.

-- 
Mit freundlichen Grüßen / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH  Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users