Virtual machine used to steal crypto keys from other VM on same server | Hacker News Reader

Virtual machine used to steal crypto keys from other VM on same server

arstechnica.com

72 pointse1ven19 comments

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!

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

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.

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.

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.

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.

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.

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/

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

VMs have been used in the Real World for going on five decades now, in the form of VM (formerly CP) on IBM System/360 mainframes et seq.

The threat model may have changed, but I don't even know if that's necessarily true.

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?

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?

a) You have to be on the same machine, and it is probably most effective if you are on the same core, since it is a cache-based probe. If the attacker does not share the same cache as the victim, this attack will not work.

b) If there are more that just the attacker and the victim on the same machine (core), it is very likely to add a lot of noise to the side channel (attack) signal since it will be busy "dirtying" the cache that the side channel attack is being carried out on. Very likely this will prevent the attack from being successful.

"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?

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)

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.

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.

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...

The scientists focused specifically on the Xen hypervisor, which is used by services such as EC2.

Are other hypervisors vulnerable to this exploit?

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

Reply on news.ycombinator.com