12:59 a.m.
This is a multi-part message in MIME format.
--------------040006070006020209070007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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=14/06/12/1349234&from=rss
Practical Cross-VM AES Full Key Recovery Attack
<http://soylentnews.org/article.pl?sid=14/06/12/1349234>
posted by janrinok <http://soylentnews.org/%7Ejanrinok/> on Thursday
June 12, @02:53PM
**
dbot <http://soylentnews.org/%7Edbot/> 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
<http://eprint.iacr.org/2014/435.pdf> [*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=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi,<br>
<br>
Maybe I should be posting to the kvm mailing list, but I think
people here should know a thing or two about it.<br>
<br>
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. <br>
<br>
But don't take my word for it as IANAC (I Am Not A Cryptographer). <br>
<blockquote><a class="moz-txt-link-freetext"
href="http://soylentnews.org/article.pl?sid=14/06/12/1349234&...
<div class="generaltitle">
<div class="title">
<h3> <a
href="http://soylentnews.org/article.pl?sid=14/06/12/1349234"&g...
Cross-VM AES Full Key Recovery Attack</a> </h3>
</div>
</div>
<div class="body"> posted by <a
href="http://soylentnews.org/%7Ejanrinok/"> janrinok</a> on
Thursday June 12, @02:53PM <br>
<strong></strong>
<div class="intro">
<p class="byline"> <a
href="http://soylentnews.org/%7Edbot/">dbot</a>
writes:</p>
<p>Researchers from Worcester Polytechnic Institute
(Worcester, MA), have published a paper illustrating a <a
href="http://eprint.iacr.org/2014/435.pdf">practical full
Advanced Encryption Standard key recovery from AES
operations preformed in one virtual machine, by another VM</a>
[<b>PDF</b>] running on the same hardware at the same
time.</p>
<p>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:</p>
<blockquote>
<div>
<p>In summary, this works:</p>
<ul>
<li>shows for the first time that de-duplication enables
fine grain cross-VM attacks;</li>
<li>introduces a new Flush+Reload based attack that does
not require interrupting the victim after each
encryption round;</li>
<li>presents the first practical cross-VM attack on AES;
the attack is generic and can be adapted to any
table-based block ciphers.</li>
</ul>
</div>
</blockquote>
<p>They target OpenSSL 1.0.1.</p>
<p>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)?</p>
</div>
</div>
</blockquote>
Kind regards,<br>
<br>
Jorick Astrego<br>
Netbulae<br>
</body>
</html>
--------------040006070006020209070007--
10:38 a.m.
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
12:05 p.m.
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.iac...
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.i...
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--
1:36 p.m.
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.
2:14 p.m.
----- Original Message -----
From: "Dan Kenigsberg" <danken(a)redhat.com>
To: "Jorick Astrego" <j.astrego(a)netbulae.eu>, 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.
2:16 p.m.
----- Original Message -----
From: "Doron Fediuck" <dfediuck(a)redhat.com>
To: "Dan Kenigsberg" <danken(a)redhat.com>
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>
> To: "Jorick Astrego" <j.astrego(a)netbulae.eu>, 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.
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
2:21 p.m.
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
2:18 p.m.
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
3814
days inactive
3815
days old
7 comments
4 participants
participants (4)
-
Dan Kenigsberg -
Doron Fediuck -
Jorick Astrego -
Sven Kieske