7 ms·

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

68 points by pronoiac 13y ago

pronoiac 13y ago
It's about AES key recovery, even from different cores.
pedrocr 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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 13y ago
        > 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…
      - pedrocr 13y ago
        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.
- higherpurpose 13y ago
  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?
  - pedrocr 13y ago
    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.
p4bl0 13y ago
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-seminar.pdf http://people.cse.nitc.ac.in/kartik/files/k4rtik-csu491-semi... I think that while a bit scary, this is quite interesting.
- akira2501 13y ago
  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.
mariusz79 13y ago
It does looks like OpenBSD team with its "hate" of virtualization was right all along
- stephenr 13y ago
  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).
- rodgerd 13y ago
  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.
  - mariusz79 13y ago
    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!
- pedrocr 13y ago
  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.
  - 13y ago
canadev 13y ago
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 13y ago
Any reason KVM is not included in the analysis? I suppose it'd be also open to this attack?

68 points by pronoiac 13y ago

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

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 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      > 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…
    - pedrocr 13y ago
      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.
higherpurpose 13y ago
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?
- pedrocr 13y ago
  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.

p4bl0 13y ago

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-seminar.pdf http://people.cse.nitc.ac.in/kartik/files/k4rtik-csu491-semi... I think that while a bit scary, this is quite interesting.

akira2501 13y ago
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.

mariusz79 13y ago

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

stephenr 13y ago
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).
rodgerd 13y ago
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.
- mariusz79 13y ago
  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!
pedrocr 13y ago
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.
- 13y ago

canadev 13y ago

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 13y ago

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