4 ms·

I've only done a quick read through the link, but I think the model they imply is that a malicious user could rent a Cloud VM in AWS/Azure/GCP/etc and then snif

I've only done a quick read through the link, but I think the model they imply is that a malicious user could rent a Cloud VM in AWS/Azure/GCP/etc and then sniff the contents of SIMD registers, similar to the Zenbleed attack which was also disclosed recently[1]. This is a big deal because optimized implementations of strcpy, strlen, and memcpy in glibc all use SIMD registers, and glibc is everywhere. 1: https://lock.cmpxchg8b.com/zenbleed.html https://lock.cmpxchg8b.com/zenbleed.html

GartzenDeHaes 3y ago
How do they know what data is in the registers? In the linked article, the person running the attack code knows what is running on the target. The target is also conveniently waiting for the attack code to run without doing anything other than referencing the target data.
- dwrodri 3y ago
  I'm gonna get put on a list for typing this out but I'll clarify: 1. Bad guy creates cloud account and spawns 10 of the cheapest VMs across different data centers, let's say this costs a total of, what... $50 a month? 2. Bad guy reads this paper, and makes a program that frequently samples SIMD registers. Contents get dumped to stdout and then streamed over an encrypted line to a RAID array hosted in $COUNTRY_WITHOUT_US_EXTRADITION. 3. Bad guy writes program to sift through data dumps on RAID array for passwords, encryption keys, etc. If you create a cloud instance right now that has an SSH login on port 22, you stream the SSH login logs and see a steady stream of attempted logins to your device. While the marginal cost of brute forcing SSH logins is free (no cloud VM needed) and my proposed scenario isn't, I think this is a very real scenario that needs monitoring.
  - DarkNova6 3y ago
    hmmm. Does this not assume that a cpu is shared among exactly 2 tenants over a long period of time? And can‘t the cloud provider simply block access to the cpu api? Like they don’t allow you to create your own threads? Just trying to understand this.
    - johncolanduoni 3y ago
      A VM cloud provider can't block you from running at least one thread, which is all the malicious threads required for this attack. However none of the big cloud providers share CPU cores between users to combat exactly this kind of thing. I really wish the people that did these disclosures were more up-front about this, instead of saying vague things like "frequently happens on modern-day computers". Though I guess you can assume that if an attack would work on AWS the researcher would definitely mention it, so the lack of such an explicit claim almost ensures the attack is not viable on major clouds.
johncolanduoni 3y ago
AFAIK none of the cloud vendors run multiple customer's VMs at the same time on the same core; even the "shared-core" virtual machines don't share timeslices (AWS goes into detail about this here[1]). [1]: https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/the-ec2-approach-to-preventing-side-channels.html https://docs.aws.amazon.com/whitepapers/latest/security-desi...

GartzenDeHaes 3y ago

How do they know what data is in the registers? In the linked article, the person running the attack code knows what is running on the target. The target is also conveniently waiting for the attack code to run without doing anything other than referencing the target data.

dwrodri 3y ago
I'm gonna get put on a list for typing this out but I'll clarify: 1. Bad guy creates cloud account and spawns 10 of the cheapest VMs across different data centers, let's say this costs a total of, what... $50 a month? 2. Bad guy reads this paper, and makes a program that frequently samples SIMD registers. Contents get dumped to stdout and then streamed over an encrypted line to a RAID array hosted in $COUNTRY_WITHOUT_US_EXTRADITION. 3. Bad guy writes program to sift through data dumps on RAID array for passwords, encryption keys, etc. If you create a cloud instance right now that has an SSH login on port 22, you stream the SSH login logs and see a steady stream of attempted logins to your device. While the marginal cost of brute forcing SSH logins is free (no cloud VM needed) and my proposed scenario isn't, I think this is a very real scenario that needs monitoring.
- DarkNova6 3y ago
  hmmm. Does this not assume that a cpu is shared among exactly 2 tenants over a long period of time? And can‘t the cloud provider simply block access to the cpu api? Like they don’t allow you to create your own threads? Just trying to understand this.
  - johncolanduoni 3y ago
    A VM cloud provider can't block you from running at least one thread, which is all the malicious threads required for this attack. However none of the big cloud providers share CPU cores between users to combat exactly this kind of thing. I really wish the people that did these disclosures were more up-front about this, instead of saying vague things like "frequently happens on modern-day computers". Though I guess you can assume that if an attack would work on AWS the researcher would definitely mention it, so the lack of such an explicit claim almost ensures the attack is not viable on major clouds.

johncolanduoni 3y ago

AFAIK none of the cloud vendors run multiple customer's VMs at the same time on the same core; even the "shared-core" virtual machines don't share timeslices (AWS goes into detail about this here[1]). [1]: https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/the-ec2-approach-to-preventing-side-channels.html https://docs.aws.amazon.com/whitepapers/latest/security-desi...