

Fine grain Cross-VM Attacks on Xen and VMware are possible - pronoiac
http://eprint.iacr.org/2014/248

======
p4bl0
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](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](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](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](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/](http://www.fileswap.com/dl/FTYVPFkN5/)
:-°)

\- Some slides: [http://people.cse.nitc.ac.in/kartik/files/k4rtik-
csu491-semi...](http://people.cse.nitc.ac.in/kartik/files/k4rtik-
csu491-seminar.pdf)

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

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

------
pedrocr
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](http://nacl.cr.yp.to/features.html)

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

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

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

~~~
p4bl0
> 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…

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

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

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

~~~
DerpDerpDerp
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.)

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

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

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

