Comment by 96718923545809
14 hours ago
Thank you for writing this.
> But if you ignore the warning and go ahead with the login, the attacker does three things: > 1. Steals your password
This shouldn't affect key-based authentication, though
Also, this from Marc-Etienne M.Léveillé email linked in your post:
> Another possibility is a compromised hosting provider. We identified a couple of them in the past where their management servers were compromised by Ebury and their customers' VPSes, containers, etc., ended up running Ebury as well.
Provider-side compromise of customer VPS instances has been a growing trend in recent years. I stopped hosting anything privacy-related on VPS in favor of dedicated hardware. Many people still don't understand how easy it is for a provider to silently dump and/or manipulate both RAM and disk space in real-time.
> This shouldn't affect key-based authentication, though
Depends what you mean by key and what you mean by affect. They can still MITM you if your using pubilc key authentication and you accept the servers host key without verifying it.
Can they? I believe SSH key bind the public key auth to the server identity, so this kind of MITM is impossible.
(Just don't turn on ForwardAgent)
> Many people still don't understand how easy it is for a provider to silently dump and/or manipulate both RAM and disk space in real-time.
That depends on the VPS technology stack being used. IIRC, at least Amazon uses hardware features like IOMMU that prevent any kind of access to the guest's memory from the host side.
AFAIK, there has never been a memory encryption scheme that successfully protects the VM client from the hypervisor, they've all been found to be defective within a few years on the market.
It is probably an useful layer because some of the attacks are not feasible for a remote attacker who has compromised the host but require actual physical access. But the marketing spiel of protecting your data from Amazon itself is just lies, physical access is more powerful than root access, no exceptions.
> But the marketing spiel of protecting your data from Amazon itself is just lies, physical access is more powerful than root access, no exceptions.
I'd trust Amazon and Google more than most others when it comes to stuff like formally verifying hardware security solutions and also doing active research against threats posed by malicious internal staff.
5 replies →
If you believe Amazon and trust there is no way that this IOMMU protection can be disabled or bypassed, I guess this is mitigation against some attacks. Seems like mostly just trusting the AWS brand name, which would be more trustworthy than fly-by-night providers even without IOMMU.
Those features are mostly to stop VM-to-VM attacks. Host will always be able to mess with it one way or another and partly it is just needed.
AMD SEV technically encrypts guest memory with key that is unavailable to hypervisor but there are still other ways to mess with VM inside, like via IO devices or the provided storage.
Is there a way from within the VM, though, to determine if that hardware feature exists and is enabled? If you don't trust your VM provider, how do you trust them when they tell you they have that feature and it is enabled?
Depends on if you don't trust them not to actually snoop on you or if you don't trust them not to get compromised by a third party. In the latter case you'd presumably trust that they deployed the feature claimed.
Yeah, memory snapshots do not esxist, sure.