4 ms·

Cache Attacks Enable Bulk Key Recovery on the Cloud

84 points by nanis 10y ago

hoodoof 10y ago
https://plus.google.com/+YonatanZunger/posts/ayXVWrFpQus https://plus.google.com/+YonatanZunger/posts/ayXVWrFpQus As +Andreas Schou said in his share, "Okay. That's it. I give up. Security is impossible."
- Bromskloss 10y ago
  To clarify, your link talks about a different, unrelated attack, right?
  - hoodoof 10y ago
    Sorry I was trying to give attribution to the quote. The quote comes from the linked page.
- groupmonoid 10y ago
  That is about an unrelated paper
gruez 10y ago
Can't this be prevented by pinning each VM to different cores?
- nanis 10y ago
  > The shared Last Level Cache (LLC) now enables true cross-core attacks [44, 8, 29] where the attacker and the victim share the CPU, but not necessarily the CPU core. Most recent LLC Prime and Probe attacks no longer rely on de-duplication [14, 25] or core sharing, making them more widely applicable.
davidpelaez 10y ago
It's very hard with posts like this to understand the true reach of the problem: is this like having ssh with "password" as the password or is it something much less dangeroues. Is this something that could be exploited without Amazon team messing with the hypervisor providing your VM or something a third party can exploit? If this is a problem with Amazon then I think it's not a real problem for many people: it's inevitable to have a trust contract with them, it's pretty much essential to the notion of the cloud. They could be effectively violating their physical security rules for employees and installing modified code on the hypervisor but they still give us hints and certifications as to why that's not the reason and we need to choose to pick that or not. I just wanted to ask because I'm not an expert on this at all and I always find myself asking, how bad is this indeed and under what assumptions is it a security problem? Any hints to understand this are much appreciated! :)
- ashitlerferad 10y ago
  The abstract answers this: any other tenants (aka third party) running on the same physical machine as your VM can steal the 2048-bit RSA keys stored in your VM. Not specific to Amazon, works with any cloud provider, there was a paper a number of years ago about this.
- sprin 10y ago
  > it's inevitable to have a trust contract with them, it's pretty much essential to the notion of the cloud. I disagree. It's possible to make good use of public infrastructure without handling any important secrets on public machines. Under certain threat models, you have to assume public infrastructure is vulnerable to coercion of the providers and side-channel attacks from co-tenants. As we are beginning to see, providers have the tools and processes to comply with coercive demands (RAM/disk dumps) and co-tenants can feasibly succeed in obtaining secrets via side-channel attacks. Under models like this, public infrastructure is still useful for storing and routing encrypted information, enabling NAT traversal, and distributing signed material which can be authenticated at the client.
lucb1e 10y ago
Wired keyboard can be read from meters away[1], your memory is transparent on shared hosting apparently, lots of installed software had multiple vulnerabilities a year... and yet we are not all compromised already. Somehow I wonder about that. Spear phishing is very effective and the software itself isn't exactly perfect either. Either very few people are even trying, or something does not add up. [1] https://www.usenix.org/legacy/events/sec09/tech/full_papers/vuagnoux.pdf https://www.usenix.org/legacy/events/sec09/tech/full_papers/... "We implemented these side-channel attacks and our best practical attack fully recovered 95% of the keystrokes of a PS/2 keyboard at a distance up to 20 meters, even through walls. We tested 12 different keyboard models bought between 2001 and 2008 (PS/2, USB, wireless and laptop)."
- slededit 10y ago
  Most houses are easily broken into, I used to break into my own as a child when I forgot my key. Yet people are ultimately moral, and only a small percent of the population will take advantage of security weaknesses.
mpnordland 10y ago
So let me get this straight, from what I gather in the abstract, I can't consider ANY information on my VPS to be secure? They can extract private keys, how long does it take? Can I mitigate this somewhat by using shorter duration keys for TLS with automatic renewal? Does this have implications for clients that process CC data?
- neopallium 10y ago
  The attack doesn't give them access to all information from another VPS on the same host. The are using timing analysis to detect what code the other VPS is executing and finding the private key from the noise caused by the victims VPS. Crypto libraries can be fixed to prevent side-channel attacks like this. The article says that libgcrypt has already been patched.
- lstodd 10y ago
  You can not consider anything on a VPS secure. The host machine has it all, anyone who has access to the host can clone your entire VPS at will, RAM and all, what security are you talking about? (you can't be sure if you rent a physical server either, but that's another topic) Besides, while the paper talks about extracting RSA keys, nothing prevents extraction of any other kind of data using the same methodology. So even if people with host acccess overlook you, nothing is secure from your neighbours. It's just that encryption keys are for some reason considered more newsworthy. Maybe because once they get access to your VPS via them, the rest is even more trivial.
niftich 10y ago
From section 9. Countermeasures > Libgcrypt 1.6.3 update: Libgcrypt recently patched this vulnerability by mak- ing the sliding window multiplication table accesses indistinguishable from each other. Thus, an update to the latest version of the library avoids the leakage ex- ploited in this work albeit only for ciphers using sliding window exponentiation. So it's already patched, assuming you patch (they say 55% of the hosts in their AWS region hasn't been patched in a year). Nonetheless, there's novel work and interesting insights in the paper, and it's a short read.
michaelbuckbee 10y ago
Trying to reason about this: so the vulnerability exists if two VMs are sharing resources within on the same physical box. If that is true, would this be mitigated by "virtual clouds" (things like https://aws.amazon.com/vpc/ https://aws.amazon.com/vpc/) or is that just taking place at the network layer?
- res0nat0r 10y ago
  VPC's are a software network layer construct, your VM's still can be launched on hosts with other customer VM's unless you are using something like 'Dedicated Hosts'.
- superuser2 10y ago
  If you want to be single-tenant but still in the "cloud" paradigm, you can get a private cloud (NOT a virtual private cloud), i.e. an OpenStack instance just for you running on dedicated servers. Some providers will administer the OpenStack part for you - they'd call that a managed private cloud.

84 points by nanis 10y ago

https://plus.google.com/+YonatanZunger/posts/ayXVWrFpQus https://plus.google.com/+YonatanZunger/posts/ayXVWrFpQus As +Andreas Schou said in his share, "Okay. That's it. I give up. Security is impossible."

Bromskloss 10y ago
To clarify, your link talks about a different, unrelated attack, right?
- hoodoof 10y ago
  Sorry I was trying to give attribution to the quote. The quote comes from the linked page.
groupmonoid 10y ago
That is about an unrelated paper

gruez 10y ago

Can't this be prevented by pinning each VM to different cores?

nanis 10y ago
> The shared Last Level Cache (LLC) now enables true cross-core attacks [44, 8, 29] where the attacker and the victim share the CPU, but not necessarily the CPU core. Most recent LLC Prime and Probe attacks no longer rely on de-duplication [14, 25] or core sharing, making them more widely applicable.

davidpelaez 10y ago

It's very hard with posts like this to understand the true reach of the problem: is this like having ssh with "password" as the password or is it something much less dangeroues. Is this something that could be exploited without Amazon team messing with the hypervisor providing your VM or something a third party can exploit? If this is a problem with Amazon then I think it's not a real problem for many people: it's inevitable to have a trust contract with them, it's pretty much essential to the notion of the cloud. They could be effectively violating their physical security rules for employees and installing modified code on the hypervisor but they still give us hints and certifications as to why that's not the reason and we need to choose to pick that or not. I just wanted to ask because I'm not an expert on this at all and I always find myself asking, how bad is this indeed and under what assumptions is it a security problem? Any hints to understand this are much appreciated! :)

ashitlerferad 10y ago
The abstract answers this: any other tenants (aka third party) running on the same physical machine as your VM can steal the 2048-bit RSA keys stored in your VM. Not specific to Amazon, works with any cloud provider, there was a paper a number of years ago about this.
sprin 10y ago
> it's inevitable to have a trust contract with them, it's pretty much essential to the notion of the cloud. I disagree. It's possible to make good use of public infrastructure without handling any important secrets on public machines. Under certain threat models, you have to assume public infrastructure is vulnerable to coercion of the providers and side-channel attacks from co-tenants. As we are beginning to see, providers have the tools and processes to comply with coercive demands (RAM/disk dumps) and co-tenants can feasibly succeed in obtaining secrets via side-channel attacks. Under models like this, public infrastructure is still useful for storing and routing encrypted information, enabling NAT traversal, and distributing signed material which can be authenticated at the client.

lucb1e 10y ago

Wired keyboard can be read from meters away[1], your memory is transparent on shared hosting apparently, lots of installed software had multiple vulnerabilities a year... and yet we are not all compromised already. Somehow I wonder about that. Spear phishing is very effective and the software itself isn't exactly perfect either. Either very few people are even trying, or something does not add up. [1] https://www.usenix.org/legacy/events/sec09/tech/full_papers/vuagnoux.pdf https://www.usenix.org/legacy/events/sec09/tech/full_papers/... "We implemented these side-channel attacks and our best practical attack fully recovered 95% of the keystrokes of a PS/2 keyboard at a distance up to 20 meters, even through walls. We tested 12 different keyboard models bought between 2001 and 2008 (PS/2, USB, wireless and laptop)."

slededit 10y ago
Most houses are easily broken into, I used to break into my own as a child when I forgot my key. Yet people are ultimately moral, and only a small percent of the population will take advantage of security weaknesses.

mpnordland 10y ago

So let me get this straight, from what I gather in the abstract, I can't consider ANY information on my VPS to be secure? They can extract private keys, how long does it take? Can I mitigate this somewhat by using shorter duration keys for TLS with automatic renewal? Does this have implications for clients that process CC data?

neopallium 10y ago
The attack doesn't give them access to all information from another VPS on the same host. The are using timing analysis to detect what code the other VPS is executing and finding the private key from the noise caused by the victims VPS. Crypto libraries can be fixed to prevent side-channel attacks like this. The article says that libgcrypt has already been patched.
lstodd 10y ago
You can not consider anything on a VPS secure. The host machine has it all, anyone who has access to the host can clone your entire VPS at will, RAM and all, what security are you talking about? (you can't be sure if you rent a physical server either, but that's another topic) Besides, while the paper talks about extracting RSA keys, nothing prevents extraction of any other kind of data using the same methodology. So even if people with host acccess overlook you, nothing is secure from your neighbours. It's just that encryption keys are for some reason considered more newsworthy. Maybe because once they get access to your VPS via them, the rest is even more trivial.

niftich 10y ago

From section 9. Countermeasures > Libgcrypt 1.6.3 update: Libgcrypt recently patched this vulnerability by mak- ing the sliding window multiplication table accesses indistinguishable from each other. Thus, an update to the latest version of the library avoids the leakage ex- ploited in this work albeit only for ciphers using sliding window exponentiation. So it's already patched, assuming you patch (they say 55% of the hosts in their AWS region hasn't been patched in a year). Nonetheless, there's novel work and interesting insights in the paper, and it's a short read.

michaelbuckbee 10y ago

Trying to reason about this: so the vulnerability exists if two VMs are sharing resources within on the same physical box. If that is true, would this be mitigated by "virtual clouds" (things like https://aws.amazon.com/vpc/ https://aws.amazon.com/vpc/) or is that just taking place at the network layer?

res0nat0r 10y ago
VPC's are a software network layer construct, your VM's still can be launched on hosts with other customer VM's unless you are using something like 'Dedicated Hosts'.
superuser2 10y ago
If you want to be single-tenant but still in the "cloud" paradigm, you can get a private cloud (NOT a virtual private cloud), i.e. an OpenStack instance just for you running on dedicated servers. Some providers will administer the OpenStack part for you - they'd call that a managed private cloud.