This is a multi-part message in MIME format. --------------030204050405060907020301 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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
--------------030204050405060907020301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hi Sven,<br> <br> Thanks for you response, I will read some more.<br> <br> 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<br> <br> What caught my attention was that it was so fast it can be done in less then a minute:<br> <br> <blockquote>Lightning-Fast Attack: <b>Even in the worst case scenario (cross-VM) the attack</b><b><br> </b><b>succeeds in less than a minute. To the best of our knowledge, no faster attack</b><b><br> </b><b>has been implemented against AES in a realistic cloud-like setting. This also</b><b><br> </b><b>means that just one minute of co-location with the encryption server suffices to</b><b><br> </b><b>recover the key.</b><br> </blockquote> <br> <pre wrap=""><blockquote type="cite"><pre wrap="">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.</pre> </blockquote> </pre> 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.<br> <br> You could hack every vulnerable customer VM in a couple of hours this way and it would all be undetected. <br> <br> <blockquote type="cite"> <pre wrap="">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.</pre> </blockquote> I'm sure there are automatic tools being built as we speak but they will not be generally available.<br> <br> <br> Kind regards,<br> <br> Jorick Astrego<br> Netbulae B.V.<br> <br> <br> <br> <div class="moz-cite-prefix">On 06/13/2014 09:38 AM, Sven Kieske wrote:<br> </div> <blockquote cite="mid:539AAAC8.3080601@mittwald.de" type="cite"> <pre wrap="">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: <a class="moz-txt-link-freetext" href="http://eprint.iacr.org/2013/448.pdf">http://eprint.iacr.org/2013/448.pdf</a> Correlation attack against openssl, polarssl and libgcrypt on xen and vmware: <a class="moz-txt-link-freetext" href="https://eprint.iacr.org/2014/248.pdf">https://eprint.iacr.org/2014/248.pdf</a> 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 </pre> </blockquote> <br> </body> </html> --------------030204050405060907020301--