Hacker News Reader

Comment by toomuchtodo | Hacker News Reader

Doesn't matter if the machine is taken over if its properly contained at the network level. Dedicated server hosting companies have been doing this for years.

View on HN

With VMs the customer can share a physical host with others and not have security concerns. This cohosting lets aws pack customers more efficiently and have much better margins for the same quality service.

With containers on bare metal, they could not cohost customers.

Uhh, even with containers you really can't cohost in a multi-tenant system. Containerization doesn't securely segregate arbitrary code in the same way traditional virtualization does, and there are still security issues with that.

I'm sure AWS is improving on this, as they need to with Lambda and its underlying containerization architecture. But everyone else? Its going to be a while before you can call it "secure".

It looks like you are in violent agreement

We are! And I love that phrase :)

Amazon offers billing by the hour for those, meaning they probably move between customers a lot more than traditional dedicated servers. A bare-metal user can do lot of bad things unless you trust your hardware manufacturing 100 %, e.g. by messing with the firmware.

At the hardware purchasing level Amazon operates with for AWS hardware, I'm sure they're able to (if they required it) spec custom BIOS requirements that perform integrity verification of subsystems before permitting power up to continue. Whether they do or not is a different question (although I'm sure someone could test this theory).

They could also just spec that firmware be stored on ROM rather than flash.

Or that a hardware jumper needs to be set on the motherboard before any firmware updates can be done.

Rackspace offers a cloud cum bare metal service called OnMetal. They flash the firmware before putting a new user on a machine.

Unless “the machine is taken over” means firmware-level compromise (e.g. disk controller, NIC controller, …), in which case the next customer allocated to that machine can be compromised despite full disk erase between customers.

I'll agree with this attack vector, although it'd be trivial to have your PXE boot routine between customers re-apply known good firmware to the NIC and disk controller and verify with checksums (unless there's a 0-day out there for the NIC controller, in which case you're owned regardless).

Normally the PXE boot code is, itself, stored in firmware.

Whatever components start first, wins. If the PXE boot code is in the NIC, you can theoretically verify the rest of the system first. If its in the BIOS, the BIOS needs to trust the NIC as untrusted/determine if its compromised or not.

Security is hard :/

ROM based NIC? Why not? If you're going into large scale dedicated servers, this is not exactly impractical. You could probably also just disconnect the flash enable pins on the ICs.

Assuming the firmware has no say in the flashing process.

It definitely does matter if the host machine is taken over... an attacker could access other customer instances, shut down the system to try and shut down EC2, etc..

If I've paid for the bare metal machine then by definition I already have root on the host machine. Securing that is just as much my problem at that point as is securing my EC2 instances.

Reply on news.ycombinator.com