
 Virtual machine used to steal crypto keys from other VM on same server - e1ven
http://arstechnica.com/security/2012/11/crypto-keys-stolen-from-virtual-machine/
======
ComputerGuru
As much as I heart ArsTechnica, the actual research was posted here on HN when
it came out: <http://news.ycombinator.com/item?id=4705147>

EDIT: post was to a cryptoanalyst's dissection of the research, as was pointed
out in the comments. I'll take that over a journalist blogger, though!

~~~
dfc
The first post was definitely better than the ArsTechnica coverage. However it
was not the actual research, the previously linked post was an analysis by a
crypto professor from JHU. The work was done by researchers at UNC, UW and
RSA, _the actual paper_ can be found here:

<http://www.cs.unc.edu/~reiter/papers/2012/CCS.pdf>

~~~
andrewcooke
that paper is pretty damn impressive - this was a huge amount of work, both in
understanding how to exploit an effective side channel, and in the statistical
processing used to extract the results from noisy data.

------
rdl
There are definitely security risks added by co-tenant VM, but there are
actually security benefits possible for virtualization if you also own the
hardware. Don't hate virtualization just because some applications make
security worse.

~~~
alexkus
I think the point being made is that given an organisation/entity that runs a
whole bunch of stuff on a bunch of VM servers then, theoretically, the most
important VM on a VM server (with regards to security/encryption) is now only
as secure as the least secure VM that runs on that same VM server.

Rather than try and hack the nailed down, up to date with patches, regulary
checked/scanned/etc payment processing VM with lots of credit card info
directly it's easier to pick off the forgotten about unpatched VM on the same
host that someone spun up to do a bit of testing and then promptly forgot
about.

IOW, if you're in control of it, don't run really important stuff on VMs
shared with a whole bunch of 'other' VMs, or make sure that everything you run
on a specific VM host is equally secure.

------
aes256
This is one of many reasons I am still wary of VMs and 'cloud' computing more
generally.

There's something about running your services on the same physical hardware as
a bunch of other, potentially malicious, parties that just gives me the
heebie-jeebies.

~~~
acdha
1\. If a side channel attack in a noisy environment is the best attack, you're
way ahead of most of the computing world

2\. This is why cloud providers offer the option of dedicated provisioning
where you can use the cloud APIs but ensure that your VMs run on hosts
dedicated to your organization.

~~~
gvb
WRT #1, a much simpler attack is to either become an employee or subvert an
employee of the VM hosting company, pause the victim VM, and read the keys out
of RAM.

<http://xkcd.com/538/>

------
scarmig
Side channel attacks always strike me as the coolest.

How practicable is this? You've got to be on the same physical machine for
this to work. Is that easily engineered for, say, EC2? Even if you can't
control whether on you're the same machine, is it possible to get any
information on the VMs that you're sharing it with?

~~~
reginaldo
I don't know how things are today, but in 2009 it was possible. See, for
instance, the paper _Hey, You, Get Off of My Cloud: Exploring Information
Leakage in Third-Party Compute Clouds_ at
<http://cseweb.ucsd.edu/~hovav/dist/cloudsec.pdf>

From the abstract: _Using the Amazon EC2 service as a case study, we show that
it is possible to map the internal cloud infrastructure, identify where a
particular target VM is likely to reside, and then instantiate new VMs until
one is placed co-resident with the target. We explore how such placement can
then be used to mount cross-VM side-channel attacks to extract information
from a target VM on the same machine._ Scared yet?

------
larrys
"One is to avoid co-residency and instead use a separate, "air-gapped"
computer for high-security tasks. "

Seriously if you were doing "high-security" task why would you be doing them
on a VM which allowed co-residency anyway?

------
apawloski
This is attack was the natural extension of Ristenpart et al's "prime, trigger
and probe" attack [1], which looks like this:

(1) Prime: Read B at s-byte offsets in order to ensure it is cached.

(2) Trigger: Busy-loop until the CPU’s cycle counter jumps by a large value.
(This means our VM was preempted by the Xen scheduler, hopefully in favor of
the sender VM.)

(3) Probe: Measure the time it takes to again read B at s-byte offsets.

The idea is that if the co-resident VM's level of activity will increase the
time it takes to read B (because the other VM cleared the CPU cache).

When they first published this, they noted that stealing cryptographic keys in
a context like EC2 seemed impractical, saying "In practice, cryptographic
cross-VM attacks turn out to be somewhat more difficult to realize due to
factors such as core migration, coarser scheduling algorithms, double
indirection of memory addresses, and (in the case of EC2) unknown load from
other instances and a fortuitous choice of CPU configuration (e.g. no
hyperthreading)."

It's really cool to see that they finally successfully implemented it.

[1]<http://cseweb.ucsd.edu/~hovav/dist/cloudsec.pdf> (PDF)

------
Xcelerate
I am absolutely amazed that you can actually do something like this. It sounds
like something theoretically possible, but too difficult to do in practice
because of so many random factors influencing each VM. Props to these guys.

~~~
pjscott
This is still very hard to pull off. These guys used a combination of several
pretty brilliant techniques, _and_ they picked a relatively easy target.

------
rcoh
This is a big deal, opening up the possibilities for more side channel attacks
against VMs located on the same physical hardware sharing CPUs and memory...

------
stephengillie
_The scientists focused specifically on the Xen hypervisor, which is used by
services such as EC2._

Are other hypervisors vulnerable to this exploit?

~~~
wmf
They probably all are, since it's really a hardware side channel. Anything
that lets two processes run on the same cache.

