4 ms·
Yup! I worked at a few companies that would co-mingle Internet facing/DMZ VMs with internal VMs. When pointing this out and recommending we should airgap thes
by Bluecobra 3y ago
Yup! I worked at a few companies that would co-mingle Internet facing/DMZ VMs with internal VMs. When pointing this out and recommending we should airgap these VMs to it's own dedicated hypervisor it always fell on deaf ears. Jokes on them I guess.
- Kwpolska 3y agoI'm pretty sure AWS/Azure/GCP don’t assign separate boxes to every customer, and somehow they’re fine.
- yencabulator 3y agoYou can pay AWS a premium to make sure you're the only tenant on the physical machine. You can also split your own stuff into multiple tenants, and keep those separate too.
- nicolas_17 3y agoAt which point you don't really need the flexibility of AWS and you might as well get a Dedicated Server elsewhere?
- yencabulator 3y agoIt'll still let you do the elastic scaling stuff, billing for actual usage instead of racked hardware.
- segfaultbuserr 3y agoEric Brandwine (VP/DE @ AWS) said publicly in 2019 that EC2 had never scheduled different tenants on the same physical core at the same time, even before we learned about these kinds of side-channel attacks. https://www.youtube.com/watch?v=kQ4H6XO-iao&t=2485s https://www.youtube.com/watch?v=kQ4H6XO-iao&t=2485s
- yencabulator 3y agoYes (lowest vCPU seems to be 2 everywhere), and that protects against this attack. However, this thread was talking about airgapping hosts, which is needed for the general threat of VM escapes.
- fulafel 3y agoAt least Fargate and Lightsail can select < 2 vCPU. (and maybe micro EC2 instance types?)
- yencabulator 3y agoWell, that does sound like those were vulnerable then, if they happened to run on Zen 2. (Obviously microcode patched by now.) As usual, cost is the biggest hindrance to security.
- vetrom 3y agoEven before then, the sufficiently paranoid (but still bound to AWS for whatever reason) would track usage/steal/IO reporting along with best guesses for Amazon hardware expidenture and use that information to size instances to attempt to coincide with 1:1 node membership.
- Bluecobra 3y agoGood point, I should have clarified that I was talking about on-prem VMs e.g. VMWare.
- akyuu 3y agoNot sure if they're actually fine, some researchers have exploited this vulnerability on AWS instances that use affected EPYC CPUs: https://twitter.com/0xdabbad00/status/1683581484337348608 https://twitter.com/0xdabbad00/status/1683581484337348608
- terom 3y agoThat sounds like it's leaking across user/process boundaries on a single EC2 instance, which presumably also requires the processes to be running on the same core. Leaks between different EC2 instances would be far more serious, but I suppose that wouldn't happen unless two tenants / EC2 instances shared SMT cores, or the contents of the microarchitectural register file was persisted across VM context switches in an exploitable manner.
- mr_toad 3y agoJust running on a separate core would avoid this bug.
- insanitybit 3y agoYes but the Firecracker VMs are pinned to specific cores. So no two tenants never share a CPU core. Other than Rowhammer, has there been a hardware vulnerability of this nature that has worked x-core? I don't recall. Still, I think that if your company is handling user data it's worth seriously considering dedicated instances for any service that encounters plaintext user information.
- fulafel 3y agoInteresting. Physical cores or SMT virtual cores? Is there a link to their docs about this?
- insanitybit 3y agoI honestly think I only ever saw an AWS Security Eng tweet about it lol sorry
- skeggse 3y agohttps://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... seems like the relevant docs?
- fulafel 3y agoThey keep breaches quiet so we don't know how porous their security is in practice.