Hacker News Reader

Comment by liquidk | Hacker News Reader

The provider has access to the host, they can just inspect the job from the outside and you won’t be able to tell

The Hetzner one is a physical server. You would need to stage a "power outage" and backdoor it, which is probably not that easy - e.g. planting a kernel module which survives kernel upgrades and is pretty advanced at hiding itself (the article talks about analyzing raw memory dump).

If it was big brother, obtaining a customised EUFI or ilo/drac/ipmi firmware for the hardware doesn't seem like a stretch.

It only takes access to a DMA-enabled bus (e.g. PCIe) though, to siphon memory contents.

And I bet PCIe is a whole lot more hotpluggable than you're officially told.

secure boot + virtualized memory encryption is supposed to prevent that, you'll have to trust intel/amd though.

Secure boot on a cloud machine is pretty useless, there's nothing stopping the hypervisor from injecting code into the running machine. Theoretically virtual machine memory is encrypted, but you'll just have to trust the hypervisor's word for it. You can try to verify the boot chain all the way to the hardware keys, but if the hypervisor just replaces your `JNE` with a `NOP` you'll have a hard time automating your protections.

I suppose you can transfer the keys out of the machine over the network (and hope the hypervisor doesn't replace the socket buffers just before transmission) and verify them off site, but guest machines will always be just that: guests on a host that has all the power.

That is not the case for the latest CPU extensions for encrypted VMs, AMD SEV-SNP and Intel TDX, which are designed to allow remote attestation based on a key hidden in the CPU that the hypervisor does not get access to.

The hypervisor only ever sees the VM’s memory in encrypted form, and it’s integrity-checked by the CPU to prevent replay attacks.

SGX has been bypassed with hypervisor access. I'm sure the new extensions are different, but have similar fundamental flaws.

Besides, a nation-state actor can compel Intel to disclose your CPU's key.

The Hetzner server used here was a dedicated, physical server.

I'm not sure truly verifiable "Secure" Boot is actually realistic in most scenarios, though, right?

I'm not super up-to-date on what's being offered right now, but I'm not sure if there is a way to have a proper trusted execution environment on most Intel or AMD offerings; I thought Secure Boot on AMD64 platforms generally rely on TPM or something like SGX for validation, with the former having seemingly a dozen different ways to be tampered with, and the latter being discontinued and being vulnerable to several different attacks, including DOWNFALL.

I think EPYC and Sapphire Rapids have some sort of Trusted Execution Environment stuff with SEV-SNP and TDX, maybe? But I don't think either option is really feasible for people paying Hetzner-like prices for hosting; Hetzner's newest Xeon offering is seemingly Cascade Lake, and the only EPYC offered is a single-socket Rome 7502P with 128GB DDR4 for 142 euros, which seems very hard to justify, given they also offer a 7950X3D with 128GB DDR5 for ~25 euros less.

Even then, I don't think I could put my confidence in a machine I don't own, didn't setup, can't physically inspect, don't know where it came from, whether the firmware has been tampered with, etc -- especially if it is something as complex as x86, where there is seemingly at least one new horrific hardware-level vulnerability that crops up every generation or two.

EDIT: I forgot Hetzner also started offering Ampere Altra servers for 200 euros. I think those have TEE of some sort with the TrustZone stuff?

Not sure how secure that really is, though; I haven't really looked into the ARM offerings as much as I should have, mostly since, if you don't want Apple, I'm not aware of a good middle-ground between a cheap SBC and a $3,000+ Ampere server, outside of jerry-rigging some second-hand Gigabyte Cavium ThunderX2 nodes off eBay.

Only if secure boot was enabled by a trusted party on trusted hardware.

If you enable secure boot remotely without physical access to the machine you can't be sure it was actually setup in a non-compromised way. For example the machine could be running a custom backdoor-ed TPM, BIOS settings, ...

Those are best for compliance to security requirements/ standards. They're not for security against state level actors.

But for some reason the attackers did not use backdoor access to the servers in this case.

Reply on news.ycombinator.com