From j.astrego at netbulae.eu Thu Jun 12 18:00:00 2014 Content-Type: multipart/mixed; boundary="===============8305177470726207514==" MIME-Version: 1.0 From: Jorick Astrego To: users at ovirt.org Subject: [ovirt-users] KSM and cross-vm attack Date: Thu, 12 Jun 2014 23:59:52 +0200 Message-ID: <539A22D8.2020704@netbulae.eu> --===============8305177470726207514== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------040006070006020209070007 Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Content-Transfer-Encoding: 7bit Hi, Maybe I should be posting to the kvm mailing list, but I think people = here should know a thing or two about it. I just read the following research paper and although the attack was = done on VMWare; from what I read about it, it could be possible with KSM = on KVM also. If you really need tight security it looks like it would be = better to disable KSM. But don't take my word for it as IANAC (I Am Not A Cryptographer). http://soylentnews.org/article.pl?sid=3D14/06/12/1349234&from=3Drss Practical Cross-VM AES Full Key Recovery Attack posted by janrinok on Thursday June 12, @02:53PM ** dbot writes: Researchers from Worcester Polytechnic Institute (Worcester, MA), have published a paper illustrating a practical full Advanced Encryption Standard key recovery from AES operations preformed in one virtual machine, by another VM [*PDF*] running on the same hardware at the same time. The attack specifically requires memory de-duplication to be enabled, and they target VMWare's VM software. Combining various attacks on memory de-duplication, and existing side channel attacks: In summary, this works: * shows for the first time that de-duplication enables fine grain cross-VM attacks; * introduces a new Flush+Reload based attack that does not require interrupting the victim after each encryption round; * presents the first practical cross-VM attack on AES; the attack is generic and can be adapted to any table-based block ciphers. They target OpenSSL 1.0.1. It will be interesting to see if the suggested countermeasure, flushing the T table cache after each operation (effective against other Flush+Reload attacks), is added to LibreSSL. Will it be left out, in the name of performance - or will they move to a different implementation of AES (not T table-based)? Kind regards, Jorick Astrego Netbulae --------------040006070006020209070007 Content-Type: text/html; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

Maybe I should be posting to the kvm mailing list, but I think people here should know a thing or two about it.

I just read the following research paper and although the attack was done on VMWare; from what I read about it, it could be possible with KSM on KVM also. If you really need tight security it looks like it would be better to disable KSM.

But don't take my word for it as IANAC (I Am Not A Cryptographer).
http://soylent= news.org/article.pl?sid=3D14/06/12/1349234&amp;from=3Drss

Practical Cross-VM AES Full Key Recovery Attack

posted by janrinok on Thursday June 12, @02:53PM  

= dbot writes:

Researchers from Worcester Polytechnic Institute (Worcester, MA), have published a paper illustrating a practical full Advanced Encryption Standard key recovery from AES operations preformed in one virtual machine, by another VM [PDF] running on the same hardware at the same time.

The attack specifically requires memory de-duplication to be enabled, and they target VMWare's VM software. Combining various attacks on memory de-duplication, and existing side channel attacks:

In summary, this works:

  • shows for the first time that de-duplication enables fine grain cross-VM attacks;
  • introduces a new Flush+Reload based attack that does not require interrupting the victim after each encryption round;
  • presents the first practical cross-VM attack on AES; the attack is generic and can be adapted to any table-based block ciphers.

They target OpenSSL 1.0.1.

It will be interesting to see if the suggested countermeasure, flushing the T table cache after each operation (effective against other Flush+Reload attacks), is added to LibreSSL. Will it be left out, in the name of performance - or will they move to a different implementation of AES (not T table-based)?

Kind regards,

Jorick Astrego
Netbulae
--------------040006070006020209070007-- --===============8305177470726207514== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KLS0tLS0tLS0tLS0t LS0wNDAwMDYwNzAwMDYwMjAyMDkwNzAwMDcKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PUlTTy04ODU5LTE7IGZvcm1hdD1mbG93ZWQKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog N2JpdAoKSGksCgpNYXliZSBJIHNob3VsZCBiZSBwb3N0aW5nIHRvIHRoZSBrdm0gbWFpbGluZyBs aXN0LCBidXQgSSB0aGluayBwZW9wbGUgCmhlcmUgc2hvdWxkIGtub3cgYSB0aGluZyBvciB0d28g YWJvdXQgaXQuCgpJIGp1c3QgcmVhZCB0aGUgZm9sbG93aW5nIHJlc2VhcmNoIHBhcGVyIGFuZCBh bHRob3VnaCB0aGUgYXR0YWNrIHdhcyAKZG9uZSBvbiBWTVdhcmU7IGZyb20gd2hhdCBJIHJlYWQg YWJvdXQgaXQsIGl0IGNvdWxkIGJlIHBvc3NpYmxlIHdpdGggS1NNIApvbiBLVk0gYWxzby4gSWYg eW91IHJlYWxseSBuZWVkIHRpZ2h0IHNlY3VyaXR5IGl0IGxvb2tzIGxpa2UgaXQgd291bGQgYmUg CmJldHRlciB0byBkaXNhYmxlIEtTTS4KCkJ1dCBkb24ndCB0YWtlIG15IHdvcmQgZm9yIGl0IGFz IElBTkFDIChJIEFtIE5vdCBBIENyeXB0b2dyYXBoZXIpLgoKICAgIGh0dHA6Ly9zb3lsZW50bmV3 cy5vcmcvYXJ0aWNsZS5wbD9zaWQ9MTQvMDYvMTIvMTM0OTIzNCZhbXA7ZnJvbT1yc3MKCgogICAg ICAgICAgUHJhY3RpY2FsIENyb3NzLVZNIEFFUyBGdWxsIEtleSBSZWNvdmVyeSBBdHRhY2sKICAg ICAgICAgIDxodHRwOi8vc295bGVudG5ld3Mub3JnL2FydGljbGUucGw/c2lkPTE0LzA2LzEyLzEz NDkyMzQ+CgogICAgcG9zdGVkIGJ5IGphbnJpbm9rIDxodHRwOi8vc295bGVudG5ld3Mub3JnLyU3 RWphbnJpbm9rLz4gb24gVGh1cnNkYXkKICAgIEp1bmUgMTIsIEAwMjo1M1BNCiAgICAqKgoKICAg IGRib3QgPGh0dHA6Ly9zb3lsZW50bmV3cy5vcmcvJTdFZGJvdC8+IHdyaXRlczoKCiAgICBSZXNl YXJjaGVycyBmcm9tIFdvcmNlc3RlciBQb2x5dGVjaG5pYyBJbnN0aXR1dGUgKFdvcmNlc3Rlciwg TUEpLAogICAgaGF2ZSBwdWJsaXNoZWQgYSBwYXBlciBpbGx1c3RyYXRpbmcgYSBwcmFjdGljYWwg ZnVsbCBBZHZhbmNlZAogICAgRW5jcnlwdGlvbiBTdGFuZGFyZCBrZXkgcmVjb3ZlcnkgZnJvbSBB RVMgb3BlcmF0aW9ucyBwcmVmb3JtZWQgaW4KICAgIG9uZSB2aXJ0dWFsIG1hY2hpbmUsIGJ5IGFu b3RoZXIgVk0KICAgIDxodHRwOi8vZXByaW50LmlhY3Iub3JnLzIwMTQvNDM1LnBkZj4gWypQREYq XSBydW5uaW5nIG9uIHRoZSBzYW1lCiAgICBoYXJkd2FyZSBhdCB0aGUgc2FtZSB0aW1lLgoKICAg IFRoZSBhdHRhY2sgc3BlY2lmaWNhbGx5IHJlcXVpcmVzIG1lbW9yeSBkZS1kdXBsaWNhdGlvbiB0 byBiZQogICAgZW5hYmxlZCwgYW5kIHRoZXkgdGFyZ2V0IFZNV2FyZSdzIFZNIHNvZnR3YXJlLiBD b21iaW5pbmcgdmFyaW91cwogICAgYXR0YWNrcyBvbiBtZW1vcnkgZGUtZHVwbGljYXRpb24sIGFu ZCBleGlzdGluZyBzaWRlIGNoYW5uZWwgYXR0YWNrczoKCiAgICAgICAgSW4gc3VtbWFyeSwgdGhp cyB3b3JrczoKCiAgICAgICAgICAqIHNob3dzIGZvciB0aGUgZmlyc3QgdGltZSB0aGF0IGRlLWR1 cGxpY2F0aW9uIGVuYWJsZXMgZmluZQogICAgICAgICAgICBncmFpbiBjcm9zcy1WTSBhdHRhY2tz OwogICAgICAgICAgKiBpbnRyb2R1Y2VzIGEgbmV3IEZsdXNoK1JlbG9hZCBiYXNlZCBhdHRhY2sg dGhhdCBkb2VzIG5vdAogICAgICAgICAgICByZXF1aXJlIGludGVycnVwdGluZyB0aGUgdmljdGlt IGFmdGVyIGVhY2ggZW5jcnlwdGlvbiByb3VuZDsKICAgICAgICAgICogcHJlc2VudHMgdGhlIGZp cnN0IHByYWN0aWNhbCBjcm9zcy1WTSBhdHRhY2sgb24gQUVTOyB0aGUKICAgICAgICAgICAgYXR0 YWNrIGlzIGdlbmVyaWMgYW5kIGNhbiBiZSBhZGFwdGVkIHRvIGFueSB0YWJsZS1iYXNlZAogICAg ICAgICAgICBibG9jayBjaXBoZXJzLgoKICAgIFRoZXkgdGFyZ2V0IE9wZW5TU0wgMS4wLjEuCgog ICAgSXQgd2lsbCBiZSBpbnRlcmVzdGluZyB0byBzZWUgaWYgdGhlIHN1Z2dlc3RlZCBjb3VudGVy bWVhc3VyZSwKICAgIGZsdXNoaW5nIHRoZSBUIHRhYmxlIGNhY2hlIGFmdGVyIGVhY2ggb3BlcmF0 aW9uIChlZmZlY3RpdmUgYWdhaW5zdAogICAgb3RoZXIgRmx1c2grUmVsb2FkIGF0dGFja3MpLCBp cyBhZGRlZCB0byBMaWJyZVNTTC4gV2lsbCBpdCBiZSBsZWZ0CiAgICBvdXQsIGluIHRoZSBuYW1l IG9mIHBlcmZvcm1hbmNlIC0gb3Igd2lsbCB0aGV5IG1vdmUgdG8gYSBkaWZmZXJlbnQKICAgIGlt cGxlbWVudGF0aW9uIG9mIEFFUyAobm90IFQgdGFibGUtYmFzZWQpPwoKS2luZCByZWdhcmRzLAoK Sm9yaWNrIEFzdHJlZ28KTmV0YnVsYWUKCi0tLS0tLS0tLS0tLS0tMDQwMDA2MDcwMDA2MDIwMjA5 MDcwMDA3CkNvbnRlbnQtVHlwZTogdGV4dC9odG1sOyBjaGFyc2V0PUlTTy04ODU5LTEKQ29udGVu dC1UcmFuc2Zlci1FbmNvZGluZzogN2JpdAoKPGh0bWw+CiAgPGhlYWQ+CgogICAgPG1ldGEgaHR0 cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9SVNPLTg4 NTktMSI+CiAgPC9oZWFkPgogIDxib2R5IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYi PgogICAgSGksPGJyPgogICAgPGJyPgogICAgTWF5YmUgSSBzaG91bGQgYmUgcG9zdGluZyB0byB0 aGUga3ZtIG1haWxpbmcgbGlzdCwgYnV0IEkgdGhpbmsKICAgIHBlb3BsZSBoZXJlIHNob3VsZCBr bm93IGEgdGhpbmcgb3IgdHdvIGFib3V0IGl0Ljxicj4KICAgIDxicj4KICAgIEkganVzdCByZWFk IHRoZSBmb2xsb3dpbmcgcmVzZWFyY2ggcGFwZXIgYW5kIGFsdGhvdWdoIHRoZSBhdHRhY2sgd2Fz CiAgICBkb25lIG9uIFZNV2FyZTsgZnJvbSB3aGF0IEkgcmVhZCBhYm91dCBpdCwgaXQgY291bGQg YmUgcG9zc2libGUgd2l0aAogICAgS1NNIG9uIEtWTSBhbHNvLiBJZiB5b3UgcmVhbGx5IG5lZWQg dGlnaHQgc2VjdXJpdHkgaXQgbG9va3MgbGlrZSBpdAogICAgd291bGQgYmUgYmV0dGVyIHRvIGRp c2FibGUgS1NNLiA8YnI+CiAgICA8YnI+CiAgICBCdXQgZG9uJ3QgdGFrZSBteSB3b3JkIGZvciBp dCBhcyBJQU5BQyAoSSBBbSBOb3QgQSBDcnlwdG9ncmFwaGVyKS4gPGJyPgogICAgPGJsb2NrcXVv dGU+PGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cDovL3NveWxlbnRu ZXdzLm9yZy9hcnRpY2xlLnBsP3NpZD0xNC8wNi8xMi8xMzQ5MjM0JmFtcDthbXA7ZnJvbT1yc3Mi Pmh0dHA6Ly9zb3lsZW50bmV3cy5vcmcvYXJ0aWNsZS5wbD9zaWQ9MTQvMDYvMTIvMTM0OTIzNCZh bXA7YW1wO2Zyb209cnNzPC9hPjxicj4KICAgICAgPGRpdiBjbGFzcz0iZ2VuZXJhbHRpdGxlIj4K ICAgICAgICA8ZGl2IGNsYXNzPSJ0aXRsZSI+CiAgICAgICAgICA8aDM+IDxhCiAgICAgICAgICAg ICAgaHJlZj0iaHR0cDovL3NveWxlbnRuZXdzLm9yZy9hcnRpY2xlLnBsP3NpZD0xNC8wNi8xMi8x MzQ5MjM0Ij5QcmFjdGljYWwKICAgICAgICAgICAgICBDcm9zcy1WTSBBRVMgRnVsbCBLZXkgUmVj b3ZlcnkgQXR0YWNrPC9hPiA8L2gzPgogICAgICAgIDwvZGl2PgogICAgICA8L2Rpdj4KICAgICAg PGRpdiBjbGFzcz0iYm9keSI+IHBvc3RlZCBieSA8YQogICAgICAgICAgaHJlZj0iaHR0cDovL3Nv eWxlbnRuZXdzLm9yZy8lN0VqYW5yaW5vay8iPiBqYW5yaW5vazwvYT4gb24KICAgICAgICBUaHVy c2RheSBKdW5lIDEyLCBAMDI6NTNQTSAmbmJzcDsgPGJyPgogICAgICAgIDxzdHJvbmc+PC9zdHJv bmc+CiAgICAgICAgPGRpdiBjbGFzcz0iaW50cm8iPgogICAgICAgICAgPHAgY2xhc3M9ImJ5bGlu ZSI+IDxhIGhyZWY9Imh0dHA6Ly9zb3lsZW50bmV3cy5vcmcvJTdFZGJvdC8iPmRib3Q8L2E+CiAg ICAgICAgICAgIHdyaXRlczo8L3A+CiAgICAgICAgICA8cD5SZXNlYXJjaGVycyBmcm9tIFdvcmNl c3RlciBQb2x5dGVjaG5pYyBJbnN0aXR1dGUKICAgICAgICAgICAgKFdvcmNlc3RlciwgTUEpLCBo YXZlIHB1Ymxpc2hlZCBhIHBhcGVyIGlsbHVzdHJhdGluZyBhIDxhCiAgICAgICAgICAgICAgaHJl Zj0iaHR0cDovL2VwcmludC5pYWNyLm9yZy8yMDE0LzQzNS5wZGYiPnByYWN0aWNhbCBmdWxsCiAg ICAgICAgICAgICAgQWR2YW5jZWQgRW5jcnlwdGlvbiBTdGFuZGFyZCBrZXkgcmVjb3ZlcnkgZnJv bSBBRVMKICAgICAgICAgICAgICBvcGVyYXRpb25zIHByZWZvcm1lZCBpbiBvbmUgdmlydHVhbCBt YWNoaW5lLCBieSBhbm90aGVyIFZNPC9hPgogICAgICAgICAgICBbPGI+UERGPC9iPl0gcnVubmlu ZyBvbiB0aGUgc2FtZSBoYXJkd2FyZSBhdCB0aGUgc2FtZSB0aW1lLjwvcD4KICAgICAgICAgIDxw PlRoZSBhdHRhY2sgc3BlY2lmaWNhbGx5IHJlcXVpcmVzIG1lbW9yeSBkZS1kdXBsaWNhdGlvbiB0 bwogICAgICAgICAgICBiZSBlbmFibGVkLCBhbmQgdGhleSB0YXJnZXQgVk1XYXJlJ3MgVk0gc29m dHdhcmUuIENvbWJpbmluZwogICAgICAgICAgICB2YXJpb3VzIGF0dGFja3Mgb24gbWVtb3J5IGRl LWR1cGxpY2F0aW9uLCBhbmQgZXhpc3Rpbmcgc2lkZQogICAgICAgICAgICBjaGFubmVsIGF0dGFj a3M6PC9wPgogICAgICAgICAgPGJsb2NrcXVvdGU+CiAgICAgICAgICAgIDxkaXY+CiAgICAgICAg ICAgICAgPHA+SW4gc3VtbWFyeSwgdGhpcyB3b3Jrczo8L3A+CiAgICAgICAgICAgICAgPHVsPgog ICAgICAgICAgICAgICAgPGxpPnNob3dzIGZvciB0aGUgZmlyc3QgdGltZSB0aGF0IGRlLWR1cGxp Y2F0aW9uIGVuYWJsZXMKICAgICAgICAgICAgICAgICAgZmluZSBncmFpbiBjcm9zcy1WTSBhdHRh Y2tzOzwvbGk+CiAgICAgICAgICAgICAgICA8bGk+aW50cm9kdWNlcyBhIG5ldyBGbHVzaCtSZWxv YWQgYmFzZWQgYXR0YWNrIHRoYXQgZG9lcwogICAgICAgICAgICAgICAgICBub3QgcmVxdWlyZSBp bnRlcnJ1cHRpbmcgdGhlIHZpY3RpbSBhZnRlciBlYWNoCiAgICAgICAgICAgICAgICAgIGVuY3J5 cHRpb24gcm91bmQ7PC9saT4KICAgICAgICAgICAgICAgIDxsaT5wcmVzZW50cyB0aGUgZmlyc3Qg cHJhY3RpY2FsIGNyb3NzLVZNIGF0dGFjayBvbiBBRVM7CiAgICAgICAgICAgICAgICAgIHRoZSBh dHRhY2sgaXMgZ2VuZXJpYyBhbmQgY2FuIGJlIGFkYXB0ZWQgdG8gYW55CiAgICAgICAgICAgICAg ICAgIHRhYmxlLWJhc2VkIGJsb2NrIGNpcGhlcnMuPC9saT4KICAgICAgICAgICAgICA8L3VsPgog ICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgIDwvYmxvY2txdW90ZT4KICAgICAgICAgIDxwPlRo ZXkgdGFyZ2V0IE9wZW5TU0wgMS4wLjEuPC9wPgogICAgICAgICAgPHA+SXQgd2lsbCBiZSBpbnRl cmVzdGluZyB0byBzZWUgaWYgdGhlIHN1Z2dlc3RlZAogICAgICAgICAgICBjb3VudGVybWVhc3Vy ZSwgZmx1c2hpbmcgdGhlIFQgdGFibGUgY2FjaGUgYWZ0ZXIgZWFjaAogICAgICAgICAgICBvcGVy YXRpb24gKGVmZmVjdGl2ZSBhZ2FpbnN0IG90aGVyIEZsdXNoK1JlbG9hZCBhdHRhY2tzKSwgaXMK ICAgICAgICAgICAgYWRkZWQgdG8gTGlicmVTU0wuIFdpbGwgaXQgYmUgbGVmdCBvdXQsIGluIHRo ZSBuYW1lIG9mCiAgICAgICAgICAgIHBlcmZvcm1hbmNlIC0gb3Igd2lsbCB0aGV5IG1vdmUgdG8g YSBkaWZmZXJlbnQKICAgICAgICAgICAgaW1wbGVtZW50YXRpb24gb2YgQUVTIChub3QgVCB0YWJs ZS1iYXNlZCk/PC9wPgogICAgICAgIDwvZGl2PgogICAgICA8L2Rpdj4KICAgIDwvYmxvY2txdW90 ZT4KICAgIEtpbmQgcmVnYXJkcyw8YnI+CiAgICA8YnI+CiAgICBKb3JpY2sgQXN0cmVnbzxicj4K ICAgIE5ldGJ1bGFlPGJyPgogIDwvYm9keT4KPC9odG1sPgoKLS0tLS0tLS0tLS0tLS0wNDAwMDYw NzAwMDYwMjAyMDkwNzAwMDctLQoK --===============8305177470726207514==-- From S.Kieske at mittwald.de Fri Jun 13 03:39:56 2014 Content-Type: multipart/mixed; boundary="===============6054704456244600319==" MIME-Version: 1.0 From: Sven Kieske To: users at ovirt.org Subject: Re: [ovirt-users] KSM and cross-vm attack Date: Fri, 13 Jun 2014 07:38:00 +0000 Message-ID: <539AAAC8.3080601@mittwald.de> In-Reply-To: 539A22D8.2020704@netbulae.eu --===============6054704456244600319== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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=C3=BC=C3=9Fen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG K=C3=B6nigsberger Stra=C3=9Fe 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Gesch=C3=A4ftsf=C3=BChrer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplement=C3=A4rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynh= ausen --===============6054704456244600319==-- From j.astrego at netbulae.eu Fri Jun 13 05:06:13 2014 Content-Type: multipart/mixed; boundary="===============0822825098311948193==" MIME-Version: 1.0 From: Jorick Astrego To: users at ovirt.org Subject: Re: [ovirt-users] KSM and cross-vm attack Date: Fri, 13 Jun 2014 11:05:37 +0200 Message-ID: <539ABEE1.1080405@netbulae.eu> In-Reply-To: 539AAAC8.3080601@mittwald.de --===============0822825098311948193== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------030204050405060907020301 Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed 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=3DUTF-8 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 pa=
rts, 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, whic=
h 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-- --===============0822825098311948193== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KLS0tLS0tLS0tLS0t LS0wMzAyMDQwNTA0MDUwNjA5MDcwMjAzMDEKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PVVURi04OyBmb3JtYXQ9Zmxvd2VkCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdiaXQK CkhpIFN2ZW4sCgpUaGFua3MgZm9yIHlvdSByZXNwb25zZSwgSSB3aWxsIHJlYWQgc29tZSBtb3Jl LgoKQnV0IGFzIHlvdSBzYXkgaXQgaGFzIGJlZW4ga25vd24gZm9yIGEgd2hpbGUgYW5kIEkgd2Fz IGF3YXJlIG9mIGl0IGZvciAKbWFueSB5ZWFycyBhbHRob3VnaCBuZXZlciBkaXZpbmcgaW50byB0 aGUgc3BlY2lmaWNzLiBJIGFsd2F5cyB0aG91Z2h0IGl0IAp3YXMgbm90IGEgcHJhY3RpY2FsIGF0 dGFjayB2ZWN0b3IKCldoYXQgY2F1Z2h0IG15IGF0dGVudGlvbiB3YXMgdGhhdCBpdCB3YXMgc28g ZmFzdCBpdCBjYW4gYmUgZG9uZSBpbiBsZXNzIAp0aGVuIGEgbWludXRlOgoKICAgIExpZ2h0bmlu Zy1GYXN0IEF0dGFjazogKkV2ZW4gaW4gdGhlIHdvcnN0IGNhc2Ugc2NlbmFyaW8gKGNyb3NzLVZN KQogICAgdGhlIGF0dGFjayoqCiAgICAqKnN1Y2NlZWRzIGluIGxlc3MgdGhhbiBhIG1pbnV0ZS4g VG8gdGhlIGJlc3Qgb2Ygb3VyIGtub3dsZWRnZSwgbm8KICAgIGZhc3RlciBhdHRhY2sqKgogICAg KipoYXMgYmVlbiBpbXBsZW1lbnRlZCBhZ2FpbnN0IEFFUyBpbiBhIHJlYWxpc3RpYyBjbG91ZC1s aWtlCiAgICBzZXR0aW5nLiBUaGlzIGFsc28qKgogICAgKiptZWFucyB0aGF0IGp1c3Qgb25lIG1p bnV0ZSBvZiBjby1sb2NhdGlvbiB3aXRoIHRoZSBlbmNyeXB0aW9uCiAgICBzZXJ2ZXIgc3VmZmlj ZXMgdG8qKgogICAgKipyZWNvdmVyIHRoZSBrZXkuKgoKCj4gRm9yIHRoZSBtb3N0IHBhcnRzLCBp dCdzIGVhc2llciB0byBoYWNrIHlvdSBtYWNoaW5lIGRpcmVjdGx5Cj4gb3Igc29jaWFsLWVuZ2lu ZWVyIHlvdXIgd2F5IGludG8gaXQsIHRoYW4gaXQgaXMgdG8gaGFjay9nZXQKPiBhY2Nlc3MgdG8g YSBkaWZmZXJlbnQgdm0gb24gdGhlIHNhbWUgc3lzdGVtIGFuZCB0aGFuIGhhY2sgYW5vdGhlciB2 bS4KClNvIHRoYXQgd2FzIHRoZSBwYXJ0IHRoYXQgd29ycmllcyBtZSwgaWYgSSBoYXZlIGEgcHVi bGljIGNsb3VkIG9mZmVyaW5nIAphbmQgc29tZW9uZSBkb2Vzbid0IGhhY2sgYSB2bSBidXQgc2lt cGx5IHJlbnRzIG9uZS4gSGUgY2FuIHRoZW4gc3Bhd24gYSAKbmV3IFZNIGV2ZXJ5IGNvdXBsZSBv ZiBtaW51dGVzIGFuZCBpdCB3aWxsIHByb2JhYmx5IGJlIG9uIGEgZGlmZmVyZW50IApob3N0IGVh Y2ggdGltZS4uLi4uIHdpdGggZGlmZmVyZW50IG5laWdoYm91cnMuCgpZb3UgY291bGQgaGFjayBl dmVyeSB2dWxuZXJhYmxlIGN1c3RvbWVyIFZNIGluIGEgY291cGxlIG9mIGhvdXJzIHRoaXMgCndh eSBhbmQgaXQgd291bGQgYWxsIGJlIHVuZGV0ZWN0ZWQuCgo+IFRoZXJlIGFyZSBhbHNvIHN0aWxs IG5vIGF1dG9tYXRpYyB0b29scyBmb3IgdGhpcywgd2hpY2ggSSdtIGF3YXJlIG9mCj4gKGlmIHRo ZXkgYXJlLCBJJ2QgbGlrZSB0byBiZSBwb2ludGVkIHRvIHRoZW0pLgo+Cj4gQXMgc29vbiBhcyBh dXRvbWF0aWMgYXR0YWNrIHRvb2xzIHdpbGwgY292ZXIgdGhpcyBzY2VuYXJpbyBJJ20gcHJldHR5 Cj4gc3VyZSB3ZSdsbCBzZWUgYW4gaW5jcmVhc2UgaW4gaGFja2VkIHZtcyBhbmQgc25pZmZlZCBw cml2YXRlIGtleXMuCkknbSBzdXJlIHRoZXJlIGFyZSBhdXRvbWF0aWMgdG9vbHMgYmVpbmcgYnVp bHQgYXMgd2Ugc3BlYWsgYnV0IHRoZXkgd2lsbCAKbm90IGJlIGdlbmVyYWxseSBhdmFpbGFibGUu CgoKS2luZCByZWdhcmRzLAoKSm9yaWNrIEFzdHJlZ28KTmV0YnVsYWUgQi5WLgoKCgpPbiAwNi8x My8yMDE0IDA5OjM4IEFNLCBTdmVuIEtpZXNrZSB3cm90ZToKPiBIaSwKPgo+IGl0J3Mga2luZCBv ZiB5b3UgdG8gbGV0IHRob3NlIGtub3cKPiBhYm91dCB0aGVzZSBhdHRhY2tzIHdobyBkbyBub3Qg YWxyZWFkeSBrbm93IHRoZW0sIGJ1dAo+IHRoaXMgc2hvdWxkIGJlIHdlbGwgdW5kZXJzdG9vZCBi eSBldmVyeSBwcm9mZXNzaW9uYWwgYnkga25vdy4KPgo+IFNoYXJlZCByZXNvdXJjZXMgYXJlIG5l dmVyIHNlY3VyZSwgaWYgeW91Cj4gY2FuIG5vdCBjb250cm9sIHRoZSBhY2Nlc3MgZnJvbSB0aGly ZCBwYXJ0aWVzCj4gdG8gc2hhcmVkIG1lbW9yeS4KPgo+IHRoaXMgZG9lcyBub3QganVzdCBhZmZl Y3QgS1NNIChvciBzaW1pbGFyCj4gdGVjaG5pcXVlcyBmcm9tIHZtd2FyZSwgeGVuIGFuZCBtaWNy b3NvZnQpCj4gYnV0IGFsc28gTDMtQ2FjaGVzIG9mIG1vZGVybiBDUFVzLgo+Cj4gSWYgeW91IGFy ZSBpbnRlcmVzdGVkIGluIHRoZXNlIHRvcGljcywgaGVyZSBhcmUgc29tZSBwYXBlcnM6Cj4KPiBM My1TaWRlLUNoYW5uZWwgYXR0YWNrIHRvIHJlY292ZXIgcHJpdmF0ZQo+IEdQRy1LZXlzIGZyb20g YW5vdGhlciBWTToKPgo+IGh0dHA6Ly9lcHJpbnQuaWFjci5vcmcvMjAxMy80NDgucGRmCj4KPiBD b3JyZWxhdGlvbiBhdHRhY2sgYWdhaW5zdCBvcGVuc3NsLAo+IHBvbGFyc3NsIGFuZCBsaWJnY3J5 cHQgb24geGVuIGFuZCB2bXdhcmU6Cj4KPiBodHRwczovL2VwcmludC5pYWNyLm9yZy8yMDE0LzI0 OC5wZGYKPgo+IEkgZG9uJ3Qga25vdyBpZiBJQk1zIFBvd2VyVk0gaXMgdnVsbmVyYWJsZSB0byBz dWNoCj4gYXR0YWNrcywgYXMgaXQncyBMUEFSIGFyY2hpdGVjdHVyZSBpcyBjZXJ0aWZpZWQKPiBF QUwgNCsgKHdoaWNoIG1pZ2h0IG5vdCB0ZWxsIGFueXRoaW5nIGFib3V0IHRoaXMgYXR0YWNrCj4g dmVjdG9yKS4KPgo+IEJ1dCB5b3UgYWx3YXlzIG5lZWQgdG8gaGF2ZSBpbiBtaW5kLCB3aGF0IGF0 dGFjawo+IHNjZW5hcmlvIHlvdSB0YWxrIGFib3V0Ogo+Cj4gVGhlc2UgYXR0YWNrcyBhcmUgYWJv dXQgYSBtYWxpY2lvdXMgdm0gKHRoaXMgY291bGQgYmUgYQo+IGhhY2tlZC9oaWphY2tlZCB2bSkg d2hpY2ggcmVjb3ZlcnMgcGFydHMgb2YgdGhlIHNoYXJlZCBtZW1vcnkKPiBmcm9tIGEga25vd24g b3RoZXIgaW5zdGFuY2UgdG8gYXR0YWNrLgo+Cj4gaWYgeW91IGhhdmUgaGlnaCBzZWN1cml0eSBj b25jZXJucyB5b3UgbWlnaHQgd2FudCBfbm90Xwo+IHRvIHNoYXJlIHlvdXIgcGh5c2ljYWwgc2Vy dmVyIHdpdGggdGhpcmQgcGFydHkgY29udHJvbGxlZAo+IHZtcywgb3Igd2l0aCB2bXMgd2hpY2gg bWlnaHQgYmUgdGhlIHRhcmdldCBvZiBnZXR0aW5nIGhhY2tlZAo+IChvciB3aGljaCBydW5zIHNv ZnR3YXJlLCB3aGljaCBpcyBrbm93biB0byBiZSB2dWxuZXJhYmxlKS4KPgo+IEkgc3RpbGwgY29u c2lkZXIgdGhpcyBzY2VuYXJpbyBub3QgYXMgdGhhdCByZWxldmFudCB0b2RheSwgYXMKPiB0aGVy ZSBhcmUgbWFueSBtb3JlIGxvdyBoYW5naW5nIGZydWl0cyAoc2FkbHkpLgo+Cj4gVGhpcyBtZWFu cyBpbiBzaG9ydDoKPgo+IEZvciB0aGUgbW9zdCBwYXJ0cywgaXQncyBlYXNpZXIgdG8gaGFjayB5 b3UgbWFjaGluZSBkaXJlY3RseQo+IG9yIHNvY2lhbC1lbmdpbmVlciB5b3VyIHdheSBpbnRvIGl0 LCB0aGFuIGl0IGlzIHRvIGhhY2svZ2V0Cj4gYWNjZXNzIHRvIGEgZGlmZmVyZW50IHZtIG9uIHRo ZSBzYW1lIHN5c3RlbSBhbmQgdGhhbiBoYWNrIGFub3RoZXIgdm0uCj4KPiBUaGVyZSBhcmUgYWxz byBzdGlsbCBubyBhdXRvbWF0aWMgdG9vbHMgZm9yIHRoaXMsIHdoaWNoIEknbSBhd2FyZSBvZgo+ IChpZiB0aGV5IGFyZSwgSSdkIGxpa2UgdG8gYmUgcG9pbnRlZCB0byB0aGVtKS4KPgo+IEFzIHNv b24gYXMgYXV0b21hdGljIGF0dGFjayB0b29scyB3aWxsIGNvdmVyIHRoaXMgc2NlbmFyaW8gSSdt IHByZXR0eQo+IHN1cmUgd2UnbGwgc2VlIGFuIGluY3JlYXNlIGluIGhhY2tlZCB2bXMgYW5kIHNu aWZmZWQgcHJpdmF0ZSBrZXlzLgo+Cj4KPiBIVEgKPgoKCi0tLS0tLS0tLS0tLS0tMDMwMjA0MDUw NDA1MDYwOTA3MDIwMzAxCkNvbnRlbnQtVHlwZTogdGV4dC9odG1sOyBjaGFyc2V0PVVURi04CkNv bnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdiaXQKCjxodG1sPgogIDxoZWFkPgogICAgPG1ldGEg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVURi04IiBodHRwLWVxdWl2PSJDb250ZW50LVR5 cGUiPgogIDwvaGVhZD4KICA8Ym9keSB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4K ICAgIEhpIFN2ZW4sPGJyPgogICAgPGJyPgogICAgVGhhbmtzIGZvciB5b3UgcmVzcG9uc2UsIEkg d2lsbCByZWFkIHNvbWUgbW9yZS48YnI+CiAgICA8YnI+CiAgICBCdXQgYXMgeW91IHNheSBpdCBo YXMgYmVlbiBrbm93biBmb3IgYSB3aGlsZSBhbmQgSSB3YXMgYXdhcmUgb2YgaXQKICAgIGZvciBt YW55IHllYXJzIGFsdGhvdWdoIG5ldmVyIGRpdmluZyBpbnRvIHRoZSBzcGVjaWZpY3MuIEkgYWx3 YXlzCiAgICB0aG91Z2h0IGl0IHdhcyBub3QgYSBwcmFjdGljYWwgYXR0YWNrIHZlY3Rvcjxicj4K ICAgIDxicj4KICAgIFdoYXQgY2F1Z2h0IG15IGF0dGVudGlvbiB3YXMgdGhhdCBpdCB3YXMgc28g ZmFzdCBpdCBjYW4gYmUgZG9uZSBpbgogICAgbGVzcyB0aGVuIGEgbWludXRlOjxicj4KICAgIDxi cj4KICAgIDxibG9ja3F1b3RlPkxpZ2h0bmluZy1GYXN0IEF0dGFjazogPGI+RXZlbiBpbiB0aGUg d29yc3QgY2FzZQogICAgICAgIHNjZW5hcmlvIChjcm9zcy1WTSkgdGhlIGF0dGFjazwvYj48Yj48 YnI+CiAgICAgIDwvYj48Yj5zdWNjZWVkcyBpbiBsZXNzIHRoYW4gYSBtaW51dGUuIFRvIHRoZSBi ZXN0IG9mIG91cgogICAgICAgIGtub3dsZWRnZSwgbm8gZmFzdGVyIGF0dGFjazwvYj48Yj48YnI+ CiAgICAgIDwvYj48Yj5oYXMgYmVlbiBpbXBsZW1lbnRlZCBhZ2FpbnN0IEFFUyBpbiBhIHJlYWxp c3RpYyBjbG91ZC1saWtlCiAgICAgICAgc2V0dGluZy4gVGhpcyBhbHNvPC9iPjxiPjxicj4KICAg ICAgPC9iPjxiPm1lYW5zIHRoYXQganVzdCBvbmUgbWludXRlIG9mIGNvLWxvY2F0aW9uIHdpdGgg dGhlCiAgICAgICAgZW5jcnlwdGlvbiBzZXJ2ZXIgc3VmZmljZXMgdG88L2I+PGI+PGJyPgogICAg ICA8L2I+PGI+cmVjb3ZlciB0aGUga2V5LjwvYj48YnI+CiAgICA8L2Jsb2NrcXVvdGU+CiAgICA8 YnI+CiAgICA8cHJlIHdyYXA9IiI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHByZSB3cmFwPSIi PkZvciB0aGUgbW9zdCBwYXJ0cywgaXQncyBlYXNpZXIgdG8gaGFjayB5b3UgbWFjaGluZSBkaXJl Y3RseQpvciBzb2NpYWwtZW5naW5lZXIgeW91ciB3YXkgaW50byBpdCwgdGhhbiBpdCBpcyB0byBo YWNrL2dldAphY2Nlc3MgdG8gYSBkaWZmZXJlbnQgdm0gb24gdGhlIHNhbWUgc3lzdGVtIGFuZCB0 aGFuIGhhY2sgYW5vdGhlciB2bS48L3ByZT4KPC9ibG9ja3F1b3RlPgo8L3ByZT4KICAgIFNvIHRo YXQgd2FzIHRoZSBwYXJ0IHRoYXQgd29ycmllcyBtZSwgaWYgSSBoYXZlIGEgcHVibGljIGNsb3Vk CiAgICBvZmZlcmluZyBhbmQgc29tZW9uZSBkb2Vzbid0IGhhY2sgYSB2bSBidXQgc2ltcGx5IHJl bnRzIG9uZS4gSGUgY2FuCiAgICB0aGVuIHNwYXduIGEgbmV3IFZNIGV2ZXJ5IGNvdXBsZSBvZiBt aW51dGVzIGFuZCBpdCB3aWxsIHByb2JhYmx5IGJlCiAgICBvbiBhIGRpZmZlcmVudCBob3N0IGVh Y2ggdGltZS4uLi4uIHdpdGggZGlmZmVyZW50IG5laWdoYm91cnMuPGJyPgogICAgPGJyPgogICAg WW91IGNvdWxkIGhhY2sgZXZlcnkgdnVsbmVyYWJsZSBjdXN0b21lciBWTSBpbiBhIGNvdXBsZSBv ZiBob3VycwogICAgdGhpcyB3YXkgYW5kIGl0IHdvdWxkIGFsbCBiZSB1bmRldGVjdGVkLiA8YnI+ CiAgICA8YnI+CiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4KICAgICAgPHByZSB3cmFwPSIi PlRoZXJlIGFyZSBhbHNvIHN0aWxsIG5vIGF1dG9tYXRpYyB0b29scyBmb3IgdGhpcywgd2hpY2gg SSdtIGF3YXJlIG9mCihpZiB0aGV5IGFyZSwgSSdkIGxpa2UgdG8gYmUgcG9pbnRlZCB0byB0aGVt KS4KCkFzIHNvb24gYXMgYXV0b21hdGljIGF0dGFjayB0b29scyB3aWxsIGNvdmVyIHRoaXMgc2Nl bmFyaW8gSSdtIHByZXR0eQpzdXJlIHdlJ2xsIHNlZSBhbiBpbmNyZWFzZSBpbiBoYWNrZWQgdm1z IGFuZCBzbmlmZmVkIHByaXZhdGUga2V5cy48L3ByZT4KICAgIDwvYmxvY2txdW90ZT4KICAgIEkn bSBzdXJlIHRoZXJlIGFyZSBhdXRvbWF0aWMgdG9vbHMgYmVpbmcgYnVpbHQgYXMgd2Ugc3BlYWsg YnV0IHRoZXkKICAgIHdpbGwgbm90IGJlIGdlbmVyYWxseSBhdmFpbGFibGUuPGJyPgogICAgPGJy PgogICAgPGJyPgogICAgS2luZCByZWdhcmRzLDxicj4KICAgIDxicj4KICAgIEpvcmljayBBc3Ry ZWdvPGJyPgogICAgTmV0YnVsYWUgQi5WLjxicj4KICAgIDxicj4KICAgIDxicj4KICAgIDxicj4K ICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gMDYvMTMvMjAxNCAwOTozOCBBTSwg U3ZlbiBLaWVza2UKICAgICAgd3JvdGU6PGJyPgogICAgPC9kaXY+CiAgICA8YmxvY2txdW90ZSBj aXRlPSJtaWQ6NTM5QUFBQzguMzA4MDYwMUBtaXR0d2FsZC5kZSIgdHlwZT0iY2l0ZSI+CiAgICAg IDxwcmUgd3JhcD0iIj5IaSwKCml0J3Mga2luZCBvZiB5b3UgdG8gbGV0IHRob3NlIGtub3cKYWJv dXQgdGhlc2UgYXR0YWNrcyB3aG8gZG8gbm90IGFscmVhZHkga25vdyB0aGVtLCBidXQKdGhpcyBz aG91bGQgYmUgd2VsbCB1bmRlcnN0b29kIGJ5IGV2ZXJ5IHByb2Zlc3Npb25hbCBieSBrbm93LgoK U2hhcmVkIHJlc291cmNlcyBhcmUgbmV2ZXIgc2VjdXJlLCBpZiB5b3UKY2FuIG5vdCBjb250cm9s IHRoZSBhY2Nlc3MgZnJvbSB0aGlyZCBwYXJ0aWVzCnRvIHNoYXJlZCBtZW1vcnkuCgp0aGlzIGRv ZXMgbm90IGp1c3QgYWZmZWN0IEtTTSAob3Igc2ltaWxhcgp0ZWNobmlxdWVzIGZyb20gdm13YXJl LCB4ZW4gYW5kIG1pY3Jvc29mdCkKYnV0IGFsc28gTDMtQ2FjaGVzIG9mIG1vZGVybiBDUFVzLgoK SWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIHRoZXNlIHRvcGljcywgaGVyZSBhcmUgc29tZSBwYXBl cnM6CgpMMy1TaWRlLUNoYW5uZWwgYXR0YWNrIHRvIHJlY292ZXIgcHJpdmF0ZQpHUEctS2V5cyBm cm9tIGFub3RoZXIgVk06Cgo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJo dHRwOi8vZXByaW50LmlhY3Iub3JnLzIwMTMvNDQ4LnBkZiI+aHR0cDovL2VwcmludC5pYWNyLm9y Zy8yMDEzLzQ0OC5wZGY8L2E+CgpDb3JyZWxhdGlvbiBhdHRhY2sgYWdhaW5zdCBvcGVuc3NsLApw b2xhcnNzbCBhbmQgbGliZ2NyeXB0IG9uIHhlbiBhbmQgdm13YXJlOgoKPGEgY2xhc3M9Im1vei10 eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly9lcHJpbnQuaWFjci5vcmcvMjAxNC8yNDgu cGRmIj5odHRwczovL2VwcmludC5pYWNyLm9yZy8yMDE0LzI0OC5wZGY8L2E+CgpJIGRvbid0IGtu b3cgaWYgSUJNcyBQb3dlclZNIGlzIHZ1bG5lcmFibGUgdG8gc3VjaAphdHRhY2tzLCBhcyBpdCdz IExQQVIgYXJjaGl0ZWN0dXJlIGlzIGNlcnRpZmllZApFQUwgNCsgKHdoaWNoIG1pZ2h0IG5vdCB0 ZWxsIGFueXRoaW5nIGFib3V0IHRoaXMgYXR0YWNrCnZlY3RvcikuCgpCdXQgeW91IGFsd2F5cyBu ZWVkIHRvIGhhdmUgaW4gbWluZCwgd2hhdCBhdHRhY2sKc2NlbmFyaW8geW91IHRhbGsgYWJvdXQ6 CgpUaGVzZSBhdHRhY2tzIGFyZSBhYm91dCBhIG1hbGljaW91cyB2bSAodGhpcyBjb3VsZCBiZSBh CmhhY2tlZC9oaWphY2tlZCB2bSkgd2hpY2ggcmVjb3ZlcnMgcGFydHMgb2YgdGhlIHNoYXJlZCBt ZW1vcnkKZnJvbSBhIGtub3duIG90aGVyIGluc3RhbmNlIHRvIGF0dGFjay4KCmlmIHlvdSBoYXZl IGhpZ2ggc2VjdXJpdHkgY29uY2VybnMgeW91IG1pZ2h0IHdhbnQgX25vdF8KdG8gc2hhcmUgeW91 ciBwaHlzaWNhbCBzZXJ2ZXIgd2l0aCB0aGlyZCBwYXJ0eSBjb250cm9sbGVkCnZtcywgb3Igd2l0 aCB2bXMgd2hpY2ggbWlnaHQgYmUgdGhlIHRhcmdldCBvZiBnZXR0aW5nIGhhY2tlZAoob3Igd2hp Y2ggcnVucyBzb2Z0d2FyZSwgd2hpY2ggaXMga25vd24gdG8gYmUgdnVsbmVyYWJsZSkuCgpJIHN0 aWxsIGNvbnNpZGVyIHRoaXMgc2NlbmFyaW8gbm90IGFzIHRoYXQgcmVsZXZhbnQgdG9kYXksIGFz CnRoZXJlIGFyZSBtYW55IG1vcmUgbG93IGhhbmdpbmcgZnJ1aXRzIChzYWRseSkuCgpUaGlzIG1l YW5zIGluIHNob3J0OgoKRm9yIHRoZSBtb3N0IHBhcnRzLCBpdCdzIGVhc2llciB0byBoYWNrIHlv dSBtYWNoaW5lIGRpcmVjdGx5Cm9yIHNvY2lhbC1lbmdpbmVlciB5b3VyIHdheSBpbnRvIGl0LCB0 aGFuIGl0IGlzIHRvIGhhY2svZ2V0CmFjY2VzcyB0byBhIGRpZmZlcmVudCB2bSBvbiB0aGUgc2Ft ZSBzeXN0ZW0gYW5kIHRoYW4gaGFjayBhbm90aGVyIHZtLgoKVGhlcmUgYXJlIGFsc28gc3RpbGwg bm8gYXV0b21hdGljIHRvb2xzIGZvciB0aGlzLCB3aGljaCBJJ20gYXdhcmUgb2YKKGlmIHRoZXkg YXJlLCBJJ2QgbGlrZSB0byBiZSBwb2ludGVkIHRvIHRoZW0pLgoKQXMgc29vbiBhcyBhdXRvbWF0 aWMgYXR0YWNrIHRvb2xzIHdpbGwgY292ZXIgdGhpcyBzY2VuYXJpbyBJJ20gcHJldHR5CnN1cmUg d2UnbGwgc2VlIGFuIGluY3JlYXNlIGluIGhhY2tlZCB2bXMgYW5kIHNuaWZmZWQgcHJpdmF0ZSBr ZXlzLgoKCkhUSAoKPC9wcmU+CiAgICA8L2Jsb2NrcXVvdGU+CiAgICA8YnI+CiAgPC9ib2R5Pgo8 L2h0bWw+CgotLS0tLS0tLS0tLS0tLTAzMDIwNDA1MDQwNTA2MDkwNzAyMDMwMS0tCgo= --===============0822825098311948193==-- From danken at redhat.com Fri Jun 13 06:36:25 2014 Content-Type: multipart/mixed; boundary="===============4372148144677376167==" MIME-Version: 1.0 From: Dan Kenigsberg To: users at ovirt.org Subject: Re: [ovirt-users] KSM and cross-vm attack Date: Fri, 13 Jun 2014 11:36:17 +0100 Message-ID: <20140613103604.GB10334@redhat.com> In-Reply-To: 539ABEE1.1080405@netbulae.eu --===============4372148144677376167== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 ma= ny > years although never diving into the specifics. I always thought it was n= ot > a practical attack vector > = > What caught my attention was that it was so fast it can be done in less t= hen > 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 a= nd > 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. --===============4372148144677376167==-- From dfediuck at redhat.com Fri Jun 13 07:14:36 2014 Content-Type: multipart/mixed; boundary="===============2612041045684450891==" MIME-Version: 1.0 From: Doron Fediuck To: users at ovirt.org Subject: Re: [ovirt-users] KSM and cross-vm attack Date: Fri, 13 Jun 2014 07:14:30 -0400 Message-ID: <389352490.25590641.1402658070138.JavaMail.zimbra@redhat.com> In-Reply-To: 20140613103604.GB10334@redhat.com --===============2612041045684450891== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Dan Kenigsberg" > To: "Jorick Astrego" , alitke(a)redhat.com, doro= n(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 w= ay > > 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 po= ssible to have an optimized cluster and a more strict one in the same DC. --===============2612041045684450891==-- From dfediuck at redhat.com Fri Jun 13 07:16:05 2014 Content-Type: multipart/mixed; boundary="===============4858479431765573316==" MIME-Version: 1.0 From: Doron Fediuck To: users at ovirt.org Subject: Re: [ovirt-users] KSM and cross-vm attack Date: Fri, 13 Jun 2014 07:16:05 -0400 Message-ID: <1517248689.25590922.1402658165274.JavaMail.zimbra@redhat.com> In-Reply-To: 389352490.25590641.1402658070138.JavaMail.zimbra@redhat.com --===============4858479431765573316== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Doron Fediuck" > To: "Dan Kenigsberg" > 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" > > To: "Jorick Astrego" , 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 w= as > > > not > > > a practical attack vector > > > = > > > What caught my attention was that it was so fast it can be done in le= ss > > > 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 offeri= ng > > > and > > > someone doesn't hack a vm but simply rents one. He can then spawn a n= ew > > > VM > > > every couple of minutes and it will probably be on a different host e= ach > > > 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 w= ill > > > 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.ovi= rt.org/Security For anything which may impact other users as well. Thanks, Doron --===============4858479431765573316==-- From S.Kieske at mittwald.de Fri Jun 13 07:20:30 2014 Content-Type: multipart/mixed; boundary="===============6455226700592686293==" MIME-Version: 1.0 From: Sven Kieske To: users at ovirt.org Subject: Re: [ovirt-users] KSM and cross-vm attack Date: Fri, 13 Jun 2014 11:18:33 +0000 Message-ID: <539ADE79.1020000@mittwald.de> In-Reply-To: 20140613103604.GB10334@redhat.com --===============6455226700592686293== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Done that: https://bugzilla.redhat.com/show_bug.cgi?id=3D1109157 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=C3=BC=C3=9Fen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG K=C3=B6nigsberger Stra=C3=9Fe 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Gesch=C3=A4ftsf=C3=BChrer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplement=C3=A4rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynh= ausen --===============6455226700592686293==-- From S.Kieske at mittwald.de Fri Jun 13 07:23:54 2014 Content-Type: multipart/mixed; boundary="===============8425643783890991260==" MIME-Version: 1.0 From: Sven Kieske To: users at ovirt.org Subject: Re: [ovirt-users] KSM and cross-vm attack Date: Fri, 13 Jun 2014 11:21:56 +0000 Message-ID: <539ADF43.9070506@mittwald.de> In-Reply-To: 1517248689.25590922.1402658165274.JavaMail.zimbra@redhat.com --===============8425643783890991260== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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.o= virt.org/Security > For anything which may impact other users as well. -- = Mit freundlichen Gr=C3=BC=C3=9Fen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG K=C3=B6nigsberger Stra=C3=9Fe 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Gesch=C3=A4ftsf=C3=BChrer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplement=C3=A4rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynh= ausen --===============8425643783890991260==--