Fine grain Cross-VM Attacks on Xen and VMware are possible | Hacker News Reader

Fine grain Cross-VM Attacks on Xen and VMware are possible

eprint.iacr.org

68 pointspronoiac23 comments

It is not the first time that the possibility of Cross-VM side-channel attacks is shown. Previous paper on the subject:

- Flush+Reload: a High Resolution, Low Noise, L3 Cache Side-Channel Attack http://eprint.iacr.org/2013/448

- Cross-VM Side Channels and Their Use to Extract Private Keys https://www.cs.unc.edu/~reiter/papers/2012/CCS.pdf

Side-channels on the web are more and more present. Non-functional behaviors carry too much information if proper countermeasures are not embedded in the design of some features. For instance with autocomplete features, it is possible to know what is being typed by someone even over HTTPS by looking at the packet traffic due to autocompletion:

- Keystroke Timing Analysis of on-the-fly Web Apps http://flyer.sis.smu.edu.sg/acns13-2.pdf

- Implementing side-channel attacks on suggest boxes in web applications http://dl.acm.org/citation.cfm?id=2490436 (did not find the PDF online for free -_-, EDIT: The file happens to be available here: http://www.fileswap.com/dl/FTYVPFkN5/ :-°)

- Some slides: http://people.cse.nitc.ac.in/kartik/files/k4rtik-csu491-semi...

I think that while a bit scary, this is quite interesting.

It's a little scary, but this particular attack is only viable against AES-128, and to a lesser extent AES-192. Using the full number of rounds in AES-256 makes cache timing attacks much less likely to succeed.

Skimmed the article quickly. This is a practical application of a timing attack on AES by Bernstein. They seem to be able to recover complete keys in all SSL libraries tested(gcrypt, openssl and polarssl). This is also completely fixed by using the hardware AES implementation in recent processors, so should basically fix itself with time as all the cloud providers upgrade systems.

Does anyone know if AES is particularly susceptible to these side-channel attacks? Are the Bernstein constructs in NaCl safer because of being easier to implement in constant time?

Edit: Apparently NaCl even includes a constant time AES implementation[1] so it would be nice to have seen it compared in this paper.

[1] http://nacl.cr.yp.to/features.html

What's important is not only "constant time implementation" but rather, as it is written on the page you linked that there are "no data-dependent branches".

Because when you have branches, even if they are perfectly balanced in time (i.e., number of instructions), it is still possible to attack on recent processors with pipelines (like in smartphones for instance), because the processor will start computing the more probable branch in advance (and if you know how it works you can compute which branch that is) and then it will actually be faster if it is actually this branch that is taken than if it is the other. It's a bit like cache timing attacks, but with code instead of data.

I was reading the features page in the NaCl site and it seems timing attacks require very careful coding to avoid. The processor will leak information all over the place (instruction count, TLB, cache, etc). NaCl even includes constant time 16 and 32 byte string comparison functions.

Instead of hoping everyone writes constant-time code are Intel/AMD working on virtualization extensions to fix these? Maybe allowing high-end CPUs to partition their cache/TLBs/BPUs per virtual host and virtualizing the instruction pointer and other cross-VM leaks.

Using the AES-NI instructions completely gets rid of the attack on AES, and hopefully future ciphers will be designed from the start for side channel resistance.

> Using the AES-NI instructions completely gets rid of the attack on AES.

I would be very, very careful before saying that. Actually I wouldn't even say it. Hardware implementation are also subject to side-channels, even when they include countermeasures. Leakage models we have for hardware are not accurate enough, and maybe they can't be. Take for instance with the power consumption side-channel: not every bit in a register leak the same (when being set or reset, they do not consume the same amount of energy / emit the same amount of EM radiation), and the actual leak depends on so many thing that the only way to know it is to measure it in the precise environment of the threat on the actual hardware that may be subject to attack. Actual hardware behavior is so difficult to predict, and side-channel attacks manage to exploit any bias, leak, glitch, anything.

Plus, there is still the possibility of fault injection attacks…

You're still hoping for no bugs and only considering the case of crypto. Maybe there are other interesting secrets recoverable with techniques like these from software written without such cares.

Edit: I wonder if similar timing attacks can be used against the VMs of scripting languages to recover code. It would be a neat hack.

I know RNG's can be vulnerable to hardware backdoors or backdoor-like weaknesses of some kind, but are hardware AES implementations vulnerable to that, too?

Extremely vulnerable I'm sure. It should be trivial for a hardware backdoor to get the key out of the AES-NI instructions and then have some kind of secret instruction to give the key to the attacker. The attacker would just need to spin up a VM on the same CPU and start extracting keys. But if you already don't trust Intel/AMD you're screwed anyway. Hardware backdoors are really scary and unverifiable.

It does looks like OpenBSD team with its "hate" of virtualization was right all along

For certain values of right. I'll take the marginal risk of security vulnerabilities over the envrionmental damage of fabbing and powering datacentres full of 99% idle servers.

How many of these server have no real purpose? So many of them host pointless websites, generate loads of useless data, or transfer tons of spam from one server to another. One badly written function, used on millions of computers that increase cpu usage by 1% more than it should will waste MWatts of power, yet nobody is worrying about that.. Thousands of new smartphone models released every year, and I don't hear people screaming about environmental damage. Want less environmental damage? Spend more time on efficient code, write everything in machine code, and don't comment on HN. After all to post one comment, how many server, switches, routers, computers need to be on? What a waste!

This is only an issue if you're hosted together with the attacker, which is indeed an issue on public cloud services. But if all the VMs on the host belong to you, as is common in corporate setups, at best this is a way to escalate a breach.

Public services could make it easier to make sure you have a whole host for yourself. I can imagine even small sites wanting to make sure that the machines doing SSL termination aren't co-hosted with anyone else.

Well, not entirely. Imagine running Windows guest on OpenBSD host. It shouldn't be a problem to infect the guest vm with some kind of a virus/trojan developed especially to take advantage of this attack vector. In this case you may be thinking that you're safer running OpenBSD as your main os, and using Windows guest to watch youtube videos, but in reality by having Flash player installed on your Win VM you can't be sure that the host has not been compromised.. So while on the paper, it may look like virtualization is safer, in reality it's a false sense of security.

I would argue that it's still safer, even though it's not completely safe.

You shouldn't view any sort of security measure as perfect, but that doesn't mean that using good practices doesn't contribute to better safety.

Using your example: attackers being reduced to performing side channel attacks after owning a VM is better than them having direct access to the host machine itself (using the same exploit), even if it's still a security flaw.

Defense in depth is a good idea, even if it's not perfect. (Note that your argument goes from "not entirely safe" to "not safer", which doesn't logically follow.)

Amazon EC2 has dedicated instances which run on single-tenant hardware.

Nothing's 100% secure. it's all about having the best trade off (best doesn't mean most secure, it means the one where you get the most of everything else without sacrificing too much security)

basically, like anything else in life, its about.. balance.

vm provide a good balance for most things. if you're holding the fate of the world tho, please dont store it in AWS - Thanks. :p

OpenBSD has several side-channel attacks possible against it's poorly-written AES-GCM implementation.

Doesn't even require a VM.

They're in the middle of fscking up OpenSSL as we write.

Right, because Amazon/etc === the sole use of virtualization?

There couldn't possibly be any companies in the world running multiple VMs on hardware they solely use (either owned or rented).

It's about AES key recovery, even from different cores.

So, if I use a VPS, how do I protect myself?

I am not clear on what to do here. I don't knowingly use AES anywhere; does using bcrypt/scrypt for my PW hashing help at all or is that unrelated?

Any reason KVM is not included in the analysis? I suppose it'd be also open to this attack?

Reply on news.ycombinator.com