Hacker News Reader

Comment by 96718923545809 | Hacker News Reader

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.

View on HN

> 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)

What does that even mean? ForwardAgent has nothing to do with it really.

No they can't.

Surely if it's someone else's hardware, they can manipulate ram and disk as well? It's just a matter of degree in how easy it is to implement.

It really depends on how paranoid you want to be. Removing their SSH keys and changing the root password will prevent casual snooping by rack-monkeys. If they need to change any hardware other than a drive they'll have to shut down the machine and you'll probably notice the gap in uptime. Keeping crucial data encrypted at rest will likely prevent pulling a mirrored drive and copying it. If that isn't enough security then you'll need to colocate and physically lock down the hardware yourself.

> 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.

Yet less than 20% of the 80+ major vulnerabilities in confidential computing have been found by cloud companies, with the majority being found by universities and independent researchers.

It's not actually in their interest to look too closely. They know they are selling snake oil, and they do not care if it works. The only function of the technology, as far as they are concerned, is to be something they can market to customers who are scared at running on public cloud, and either they never intend to exploit it, in which case it doesn't matter if it doesn't work, or they do, in which case they don't want the vulnerabilities to be found and fixed. Either way, there is no upside to them for going spelunking.

> It's not actually in their interest to look too closely. They know they are selling snake oil, and they do not care if it works.

I can tell you from direct experience on the inside at AWS that they care tremendously about virtualization security.

It's why they never let two tenants share a physical core simultaneously; they were prepared against side-channel attacks before Spectre and Meltdown were discovered.

It's why they never supported Intel SGX, preferring instead to sequester processors for confidential workloads (Nitro Enclaves), and why modern EC2 instances support memory encryption (Graviton + AMD SEV-SNP).

It's why, when you improperly remove a chassis from its cabinet, a mechanism destroys a key component containing the machine's attestation and encryption keys, rendering it useless.

It's why they delegated a large amount of security surface, including practically all I/O functions, to their off-CPU Nitro card.

They care tremendously about virtualization security, when the threat model is one of their tenants attacking another one of their tenants.

They care not one bit about virtualization security when the threat model is themselves attacking one of their tenants.

> They care not one bit about virtualization security when the threat model is themselves attacking one of their tenants.

This claim deserves substantiation. What evidence do you have of this?

Are you aware, for example, that their own personnel have no login capability to EC2 metal?

and yet they have solutions in place to work around all that to do all sorts of things with all there customers data without any customers knowledge because for example law enforcement agencies may demand that for one of there customers one day...

Fact is if you put it in the cloud you lost control. Data, services and integrity is gone. Uploading your stuff to Pirate Bay may actually be more secure because downloading it is maybe illegal :-)

> and yet they have solutions in place to work around all that to do all sorts of things with all there customers data without any customers knowledge

Such as what? Point to examples, please; don't just thread-crap hand-wavy statements like this.

Customers are free to--and are in fact encouraged to--use their own keys to encrypt their data both in transit and at rest.

> Fact is if you put it in the cloud you lost control. Data, services and integrity is gone.

The alternatives are arguably worse. You can't get anywhere near the durability of a cloud provider with any economically feasible alternative. Moreover, regardless of where you store data, law enforcement will be able to demand it be turned over with a valid warrant, and it's far easier for them to break down your door and collect it from your homelab servers (or just walk away with them under their arms) than to get into a Tier 1 cloud provider's data center and decrypt the encrypted data from it.

Is this a fair comparison? Why would we know about a cloud provider finding a vulnerability in their own product? Wouldn’t that be kept internal?

Vulnerabilities are typically fixed, and then reported.

Reported to whom? In this case, it's the cloud provider itself.

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.

> like via IO devices or the provided storage.

... which AWS provides via the dedicated Nitro card to the VMs directly.

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.

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.

> Is there a way from within the VM, though, to determine if that hardware feature exists and is enabled?

Yes, as long as you trust AMD's implementation to not be broken, which to my knowledge hasn't happened yet.

Yeah, memory snapshots do not esxist, sure.

Reply on news.ycombinator.com