4 ms·
When I was a junior sysadmin at a hosting company I raised this point in passing. It was acknowledged as a problem, but apparently so hard to fix that it was ju
by switch007 9y ago
When I was a junior sysadmin at a hosting company I raised this point in passing. It was acknowledged as a problem, but apparently so hard to fix that it was just ignored (and I didn't care enough to pursue it further).
I haven't given it much thought as I've not worked with physical kit since then. I wonder if virtualization is good enough now that they could take a security stance to only deploy VMs, and deprecate the root "physical servers" product offering (i.e. you can spec out a physical server but you will always get a VM).
- db48x 9y agoNo, they're not good enough. If you can read what's in the memory or disk images, then you can find all the interesting things there are to find.
- richardwhiuk 9y agoHuh? Memory and disk should be independent for each VM? Short answer - yes using VMs should be good enough.
- db48x 9y agoIf I install a custom bios, it doesn't matter where the VM images are stored, or what format they are stored in. The bios can read them all.
- switch007 9y agoI'm quite confused about the situation and attack vector you're describing. Could you explain? If you had direct (root) access to the hardware, you can replace firmwares/BIOS, which is what we are discussing. However, as I'm suggesting, if that machine was only ever provisioned with a VM, the bad actor is not given access to the hardware directly (hypervisor bugs aside)
- db48x 9y agoYou can't count on the hypervisor being bug-free, and hardware moves from machine to machine. If compromised hardware gets into your machine, regardless of the route, the fact that your programs are running in a VM won't save you.